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Preface 


This book is a reference manual for system programmers who must provide 
operators with the detailed information needed to operate the Advanced 
Communications Function for VTAM (ACF/VTAM) program product. 


ACF/VTAM can operate with the ACF Network Control Program 
(ACF/NCP/VS) Release 2, Release 2.1, or Release 3. This publication uses 
the term NCP to refer to all of these supported releases of ACF/NCP/VS, 
unless reference to a specific release is made. Any reference to ACF/NCP/VS 
Release 2 applies to both ACF/NCP/VS Release 2 and ACF/NCP/VS Release 
2.1, unless otherwise stated. 


Some of the functions available in ACF/VTAM Release 3 (such as multiple 
routes between subareas) cannot be used unless ACF/NCP/VS Release 3 is 
installed. Likewise, if the Multisystem Networking Facility is installed, some of 
the functions available in ACF/VTAM Release 3 cannot be used as they apply 
to other host subarea nodes unless ACF/VTAM Release 3 or ACF/TCAM 
Version 2 Release 3 is installed in such other host subarea nodes. Refer to 
ACF/VTAM Planning and Installation Reference for more information on these 
functional limitations. 


The description of ACF/VTAM operation in this manual assumes a network 
consisting of ACF/VTAM Release 3, ACF/NCP/VS Release 3, and 
ACF/TCAM Version 2 Release 3 nodes. Special considerations that apply to 
ACE/VTAM operation in a network containing other supported nodes are 
supplied as migration considerations at the end of each section, as appropriate. 


In this manual, the Virtual Storage Extended (VSE) operating system, 
comprising the DOS/VSE system control programming (SCP) and the 
VSE/Advanced Functions program product, is referred to as the VSE system. 


How to Use This Manual 


This manual provides an introduction to operating ACF/VTAM (Chapter 1), 
provides information for developing operating procedures for an ACF/VTAM 
network (Chapter 2), provides information for developing backup and recovery 
procedures for an ACF/VTAM network (Chapter 3), describes the syntax of 
ACF/VTAM operator commands (Chapter 4), and provides examples of output 
from ACF/VTAM DISPLAY commands (Appendix A). 


In Chapter 4, the commands and their descriptions appear in alphabetical order 
by command name and principal modifier. (For example, VARY is considered 
a class of commands, and VARY ACT is considered a specific command.) The 
description of each command includes a summary of the command’s function, | 
the command format, a list of the resource types for which each operand is 
allowed (if applicable), and a description of each operand. 


_ To make the best use of this manual, you should be familiar with the operation 
of the host operating system (OS/VS1, OS/VS2 [MVS], or VSE). In addition, 
you should have the. necessary background knowledge about ACF/VTAM as 
provided in the prerequisite publications listed below. 
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Prerequisite Publications 


Related Publications 


ACF/VITAM Publications 


Advanced Communications Function for VTAM General Information: Concepts, 
GC27-0463 


This publication provides an overview of ACF/VTAM. It is directed primarily 
to data processing managers and system programmers who might install or 
maintain a data communication system that uses ACF/VTAM. 


Advanced Communications Function for VTAM Planning and Installation 
Reference, SC27-0584 


This publication provides information needed to plan an ACF/VTAM 
installation, to include ACF/VTAM in a VSE or OS/VS operating system, and 
to define an ACF/VTAM domain. 


As shown in Figure P-1, this book is part of a library of ACF/VTAM 
publications. The following paragraphs provide a brief description of each 
ACF/VTAM publication, except for the prerequisite publications previously 
described. The order of these descriptions corresponds to the order in which 
the publications are shown in Figure P-1. 


Advanced Communications Function for VTAM Program Summary, GC27-0457 


This publication provides a summary of ACF/VTAM Release 2 and 3 facilities. 
It also provides a brief description of the operating environment in which 
ACF/VTAM is expected to run and information about the availability of the 
ACF/VTAM program product. 


Advanced Communications Function for VTAM General Information: 
Introduction, GC27-0462 


This publication provides an overview of ACF/VTAM Release 2 and3_ 
facilities, hardware and software requirements, and other information needed to 
evaluate the applicability of the ACF/VTAM program product to an | 
installation. 


Advanced Communications Function for VTAM Programming, SC27-0449 


This publication explains how to write an ACF/VTAM application program, 
including application programming facilities and macro instructions. It also 
provides information on writing program operator and communication network 
management (CNM) application programs. . 


Advanced Communications Function for VTAM Reference Summary, 
SX27-0008 


This publication contains a summary of ACF/VTAM operator commands, a 
summary of the ACF/VTAM macro instructions, various macro error return 
codes, and a. summary of certain SNA information. 


Evaluation and Education 


ACF /VTAM General 


| ACF /VTAM Program ihoroetians 


Summary, 


GC27-0457 Introduction, 


GC27-0462 


ACF /VTAM General 
Information: 


| Concepts, 


GC27-0463 


InstaHing ACF/VTAM 


| ACF /VTAM 
Planning and 

| Installation 
Reference, 
SC27-0584 
(OS/VS and VSE) 


Writing ACF/VTAM Application Programs 


A Feel General _| ACF/VTAM 

: Programming, 
Concepts, | $C27-0449 
GC27-0463 | 


| Operating ACF/VTAM 


_§ ACF/VTAM 
Pe Operation, 
f SC27-0466 


ACF /VTAM 


Reference Summary, | 
S$X27-0008 | 
| {(OS/VS and VSE) 


ACF /VTAM 
Messages 

and Codes, 
SC27-0470 
(OS/VS and VSE) 


Detecting, Diagnosing, and Fixing Problems 


| ACF /VTAM ACF /VTAM 


| Diagnosis | Diagnosis 
Guide, ” Reference, 
; SY38-3029 (OS/VS) | LY38-3027 (OS/VS) 


SY38-3020 (VSE) | LY38-3022 (VSE) 


| ACF/VTAM Logie: 
Multisystem 
Networking 


Facifity, 
| LY38-3023 


Figure P-1. ACF/VTAM Release 3 Publications 


ACF /VTAM 
Data Areas, 
LY38-3030 (OS/VS) |} 
LY38-3026 (VSE) : 


ACF/VTAM Logic: 
Encrypt/Decrypt 
| Feature, 
LY38-3025 
(OS/VS only) 


Preface ili 


Advanced Communications Function for VTAM Messages and Codes, 
SC27-0470 7 


This publication is a reference manual for ACF/VTAM messages and the 
related routing codes, descriptor codes, and suppression levels. 


Advanced Communications Function for VTAM Diagnosis Guide, SY38-3029 
(OS/VS), SY38-3020 (VSE) 


This publication describes procedures and service aids used to isolate and 
describe ACF/VTAM problems. 


Advanced Communications Function for VTAM Diagnosis Reference, 
LY38-3027 (OS/VS), LY38-3022 (VSE) 


This publication describes the logic of ACF/VTAM and can be used for 
reference when debugging ACF/VTAM. 


Advanced Communications Function for VTAM Data Areas, \.Y38-3030 
(OS/VS), LY38-3026 (VSE) 


This publication contains diagrams and information about data areas and control 
blocks used by ACF/VTAM. 


Advanced Communications Function for VTAM Logic: Multisystem Networking 
Facility, LY38-3023 


This publication describes the logic of the ACF/VTAM Multisystem 
Networking Facility and can be used for reference when debugging an 
ACF/VTAM system that has this facility installed. 


Advanced Communications Function for VTAM Logic: Encrypt/ Decrypt Feature, 
LY38-3025 


This publication describes the logic of the ACF/VTAM Encrypt/Decrypt 
Feature and can be used for reference when debugging an ACF/VTAM system 
that has this feature installed. 


Systems Network Architecture (SNA) Publications 


The following publications will provide ACF/VTAM users with uscful 
background information about Systems Network Architecture (SNA). 


Systems Network Architecture Concepts and Products, GC30-3072 (when 
available) | 


This publication introduces the IBM Systems Network Architecture to 
individuals who need to acquaint themselves with its benefits, its concepts, and 
the IBM products that are designed for use in SNA networks. This is the basic 
publication about SNA for managers, system designers, and others involved in 
making decisions about planning or implementing SNA networks. 


Systems Network Architecture Technical Overview, GC30-3073 (when available) 
This publication presents detailed information on the structure and functions of 


SNA for the designers, installers, programmers, and administrators of SNA 
networks. 


ACF/NCP/VS Publications 


The following publications contain information on NCP installation and 
generation, as well as information on loading and dumping an NCP and printing 
NCP dumps. 

ACE/NCP/VS Reiease 3 Publications 


ACF/NCP/VS Network Control Program and System Support Programs 
Installation, SC30-3154 


ACF/NCP/VS Network Control Program and System Support Programs 
Utilities, SC30-3158 


ACF/NCP/YS Reiease 2 Publications 
ACF/NCP/VS Installation, SC30-3142 
ACF/NCP/VS Utilities, SC30-3143 

Operating System Publications 
The following publications contain information about operating the VSE, 
OS/VS1 and OS/VS2 (MVS) operating systems, including starting and 
canceling programs that use ACF/VTAM under these operating systems. 
VSE/Advanced Functions: Operating Procedures, §SC33-6097 
Operator’s Library: OS/VS1 Reference, GC38-0110 
Operator’s Library: OS/VS2 Reference (JES2), GC38-0210 
Operator’s Library: OS/VS2 Reference (JES3), GC38-0226 
The following publications contain information about the Generalized Trace 
Facility (GTF), which is needed to print ACF/VTAM trace data in OS/VS 
operating systems. 


OS/VSI1 Service Aids, GC28-0665 


OS/VS2 System Programming Library: Service Aids, GC28-0674 
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Network Communications Control Facility (NCCF) Publication 
The following publication contains information about the Network 
Communications Control Facility (NCCF), which can be used to assist in 


operating an ACF/VTAM network. 


Network Communications Control Facility General Information, GC27-0429 
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Changed Documentation 


This manual has been completely rewritten, with extensive changes to both the 
organization and the contents of the manual. Users of previous editions of this 
manual should review it in its entirety. 


This edition applies only to ACF/VTAM Release 3. Usérs of ACF/VTAM 
Release 2 should use this manual only for planning migration to ACF/VTAM 
Release 3. 


New Program Functions 


New ACF/VTAM commands have been added and existing commands have 
been changed in both syntax and operational characteristics. Following is a list 
of the ACF/VTAM commands that are new or changed for ACF/VTAM 
Release 3, with a brief description of the new commands and a summary of the 
syntax changes of the changed commands. 


« DISPLAY PATHTAB. The PATHTAB operand is now a positional 
parameter and must immediately follow the NET operand. The DISPLAY 
ROUTE. command is intended to be a replacement for the DISPLAY 
PATHTAB command, but DISPLAY PATHTAB is still available. 


¢ DISPLAY ROUTE. This command is new for ACF/VTAM Release 3. It 
displays the status of routes between Subarea nodes, and optionally tests 
such routes. 


¢ DISPLAY STATIONS. This command is new for ACF/VTAM Release 3. 
It displays the status of link stations. 


« DISPLAY U. This command is for OS/VS2 (MVS) only and is new for 
ACE/VTAM Release 3. It displays information about TSO users. 


¢ HALT. This command is changed for ACF/VTAM Release 3: the syntax 
of the CDLINK operand has been improved. 


« MODIFY DUMP. This command is changed for ACF/VTAM Release 3: 
there is a new DUMPSTA operand to control the dumping of an NCP. 


« MODIFY IOPD. This command is new for ACF/VTAM Release 3. It 
controls the interval of operator notification for pending ACF/VTAM 
operations. 


e MODIFY MSGMOD. This command is new for ACF/VTAM Release 3. 


It causes identification of the issuing module to be included in ACF/VTAM 


operator messages. 
« MODIFY TRACE and MODIFY NOTRACE. These commands are 
changed for ACF/VTAM Release 3: 
— There is anew EVERY operand for TYPE=BUF and TYPE=IO to 
extend the scope of the command. 


— There is a new TG operand for NCP transmission group trace. 


= There is a new TSO operand (OS/ VS2 [MVS] only) for TSO trace. 


— There are new internal trace options. 


e VARY ACQ. This command is changed for ACF/VTAM Release 3: the 
REP operand is now obsolete. If it is specified, it is ignored. | 


« VARY ACT. This command is changed for ACF/VTAM Release 3: 


— The COLD operand is now obsolete. If it is specified, it is ignored and 
the default value for the SCOPE operand is used. (This is fully 
compatible with the COLD function available in previous releases of 
ACF/VTAM. ) 


— The syntax of the RNAME operand has been changed. Also, this 
operand and the U operand are no longer mutually exclusive. 


—- The RNAME operand is no longer meaningful for an activation of a 
link station and is not allowed, except for a specific migration case. 


— There are new DUMPSTA, LOADSTA, and LOAD operands to control 
the dumping and loading of an NCP. 


« VARY INACT. This command is changed for ACF/VTAM Release 3: the 
syntax of the CDLINK operand has been improved. 


There are new CDRSCTI, IOINT, MSGMOD, SONLIM, and USSTAB start 
options. 


There are also changes to ACF/VTAM operating procedures: 


e Path definitions are now required in a network that has more than one 
subarea. 


e There are changes to the procedures for activating, deactivating, acquiring, 
and releasing NCPs to account for the expanded connection abilities of 
NCPs. 


¢ The options for dumping and reloading NCPs during error recovery 
procedures are enhanced to provide control with respect to the multiple 
connections now possible with an NCP. 


* The DISPLAY command output has been enhanced to include information 
on new ACF/VTAM Release 3 functions. 


« Existing ACF/VTAM messages have been changed and new messages have 
been created to include information on new ACF/VTAM Release 3 
functions. 


e Inactive NCPs can appear in ACF/VTAM display output if they have been 
contacted through active adjacent link stations. 


« Certain types of failure or error recovery situations can affect the operation 
of the VARY TERM command. 


e The reprentations of communication controller channel attachments have 
been formalized into cross-subarea links and link stations, analogous to 
SDLC links and link stations. While the VARY ACT command is not 
allowed for channel links and link stations, the VARY INACT command 1s 
allowed. 


The VARY ACT and VARY INACT commands are now allowed for any 
cross-subarea SDLC links and link stations. 


Cross-subarea links and link stations in a node adjacent to an NCP node 
being activated can be automatically activated as part of that NCP 
activation. Deactivation of such links and link stations can also be 
automatic. 
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Chapter 1. Introduction 


The ease with which ACF/VTAM can be operated depends in part on the 
decisions made when defining the ACF/VTAM domain and on the operating 
procedures developed by the user. This book is intended as a source of 
information necessary to develop operating procedures for an ACF /VTAM 
domain, and as a reference manual for ACE/VTAM operator commands when 
operating an ACF/VTAM domain. 


In this manual, the person who defines an ACF/VTAM domain and develops 
the operating procedures for it is called a system programmer, and the person 
who receives ACF/VTAM messages and enters ACF/VTAM operaior 
commands is called an ACF/VTAM operator or, for brevity, just operator. \n < 
multiple-domain network, the operators in the various domains are referred to 

aS domain operators. 


Controlling an ACF/VTAM Domain 


Both the system programmer and the ACF/VTAM operator control 
ACF/VTAM. The system programmer defines the ACF/VTAM domain and, 
in doing so, establishes the basic operating parameters of ACF/VTAM and the 
amount of information that ACF/VTAM must obtain from the operator. After 
ACF/VTAM is started, the operator can monitor the status of the domain (for 
example, determine whether a resource is active or inactive) and change the 
status as required. The system programmer should help the operator by 
defining the domain so as to make the best use of ACF/VTAM operating 
facilities for the installation configuration, and by providing detailed opcrating 
procedures for the domain. 


The Role of the ACF/VTAM Operator 


The ACF/VTAM operator interacts with the operating system and with 
ACF/VTAM to monitor and control network resources within the ACF /VTAM 
domain. Following the procedures devised by the system programmer, the 
operator participates in the operation of the domain by receiving and responding 
to ACF/VTAM messages, and by entering commands to change the way in 
which the domain is operating. ACF/VTAM operator tasks include: 


¢« Starting and stopping ACF/VTAM 


e Making channel-attached devices available to ACF/VTAM 


« Establishing and modifying the configuration of the domain to control the 
use of programs, terminals, and other resources in the domain 


¢ Monitoring domain activity by displaying the status of resources in the 
domain 


« Using diagnostic aids (such as traces, link tests, and dumps) when 
necessary, to provide information for locating and fixing problems in the 
network 


e Recovering from network failures by following appropriate backup 
procedures 
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The Role of the System Programmer 


The system programmer can define an ACF/VTAM domain to include the use 
of programs to assist the operator in running the domain. These can include 
program operators and communication network management (CNM) application 
programs. See “Controlling the ACF/VTAM Domain with the Help of 
Application Programs” in Chapter 2 for more information. In this manual, the 
term ACF/VTAM operator applies to both human operators and program 
operators. 


The system programmer can simplify starting the ACF/VTAM domain by 
defining: 

e Start procedures 

¢« Start option lists 

e« Configuration lists 


The use of the configuration restart facility can also be defined, to simplify 
restarting all or part of the domain. 


The system programmer must provide the information needed by the operator to 
start and control ACF/VTAM. This information includes: 

e Start options that the operator must enter (if any) 

e The syntax of any operator commands modified by the use of USS tables 


e The name and type of each domain resource; specifically, the names of: 


— Path definition sets to be activated by the operator 
-— Application programs and their associated job names 
~ Channel-attached non-SNA terminals 

- Channel-attached physical units and logical units 


— NCPs and their subordinate resources (such as lines, link stations, 
physical units, and logical units) 


- Physical units and logical units communicating over switched lines 


e The names and subarea addresses of all subarea nodes, if there is more than 
the one subarea of the ACF/VTAM host, along with a map showing their 
interconnections, and one or more maps showing the explicit and virtual 
routes to each destination subarea | 


e If the system is to engage in cross-domain communication: 
— Maps of the network, including all other-domain subarea nodes through 
which this domain has routes 


— The names of resources in other domains with which this domain is to 
communicate 


— The names of cross-domain.resource managers for those resources 


~ Procedures for taking over and returning the resources of one or more | 
NCPs in another domain, if the operator is to provide backup for other 
domains 


e Guidance concerning: 


— Activating and deactivating parts of the domain 

— Monitoring domain resources 

— Establishing and terminating sessions with operator commands 
— Using ACF/VTAM trace facilities 

— Requesting NCP loads, dumps, and storage displays 

— Changing the configuration of a communication controller 

— Testing routes 

— Testing SDLC lines 

— Requesting detailed error information concerning SDLC lines 
— Requesting TOLTEP tests 

— Halting ACF/VTAM 


Note: The operating procedures supplied by the system programmer should not 
depend on internal ACF/VTAM execution sequences. That is, ACF/VTAM 
commands entered at nearly the same time can be processed in parallel and the 
order of processing of the commands should net be assumed to be the same as 
the order in which the commands are entered. In particular, if one command 
depends on the successful completion of another, the dependent command should 
not be entered until the successful completion of the first command is confirmed 
by an ACF/VTAM message. 


Connection of Subareas 


Each ACF/VTAM domain is divided into subareas. A subarea is a host 
processor or a communication controller and the resources associated with it. 


Subareas are joined by logical links called transmission groups. The system 
programmer can define up to eight transmission groups between NCP nodes, 

and one transmission group between a host node and an NCP node. A 
transmission group is composed of one or more cross-subarea links. Specifically, 
a transmission group can contain one channel link, or one or more SDLC links. 


For every cross-subarea link in a subarea node, there is a link station, which is a 


named resource within a subarea node representing the attachment of another 
subarea node by the cross-subarea link. 
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For two NCPs connected by an SDLC communication line, a link and a link 
station are defined and named in each NCP. The link is defined using the 
LINE macro, and the link station is defined using the PU macro with 
PUTYPE=4 specified. For example, in Figure 1-1, the SDLC line between 
NCP1 and NCP2 is defined as LINK1 in NCP1 and as LINK2 in NCP2. 
Similarly, a link station is defined in each NCP: 


LINKSTAI1, which is defined in NCP1 and represents the attachment of 
NCP2 | 


LINKSTA2, which is defined in NCP2 and represents the attachment of 
NCP1 


For an NCP connected directly to a host processor channel, a channel link and 
a channel link station are dynamically defined by ACF/VTAM when the 
channel-attached NCP is activated. Channel links and link stations are named 
by ACF/VTAM, which creates the name by taking the channel device name for 
the communication controller and adding “-L”’ for the link name and “-S”’ for 
the link station name. For example, the channel device name 0C2 has the link 
name of O0C2-L and a link station name of O0C2-S. 


A transmission group becomes active when any one of the link stations within 
the group becomes active, and a transmission group becomes inactive when the 
last link station within the group becomes inactive. Conversely, a link and its 
link station become part of a transmission group when the link station becomes 
active, and they are no longer part of a transmission group when the link station 
becomes inactive. If one of the links or link stations in a multi-link transmission 
_ group fails or is deactivated, session traffic continues on the remaining links in 
the group without loss of data. | 


A transmission group number can be defined for a link station, or the link 
station can be defined to use the transmission group number defined for the link 
station at the other end of the link. (Thus a specific transmission group number 
must be defined for at least one of the two sides of a cross-subarea link.) The 
transmission group number for a transmission group containing a channel link is 
not defined by the system programmer and is always 1. 


Cross-subarea links and link stations must be active on both sides of an SDLC 
communication line before the subareas they connect can communicate with 
‘each other. Also, the link associated with a link station must be active before. 
the link station itself can be activated. For example, in Figure 1-1, LINK1 must 
be active before LINKSTAI1 can be activated. 


The NCP has a optional facility called SDLC monitor mode, which enables an 
NCP to automatically activate its cross-subarea SDLC links and link stations 
without the aid of an SSCP. Monitor mode is required in some cases, such as 
for the activation of LINK2 and LINKSTA2 in Figure 1-1 (because the link and 
link station must be active to support the session that ACF/VTAM needs with 
NCP2 in order to activate NCP2, and ACF/VTAM cannot activate LINK2 and 
LINKSTA2 until NCP2 is activated). Monitor mode might be desirable in cases 
where it is not required. For example, it can be used to make cross-domain 
session traffic possible without waiting for each host in the network to activate 
the necessary links and link stations. However, such an optional use of monitor 
mode should not completely take the place of activation by ACF/VTAM, 
because activation by ACF/VTAM is required for error recovery procedures 


Host Processor 
with ACF/VTAM 


0C2-L 


LINKSTA? | 


LINKSTA2 
LINK2 


NCP2 


Figure t-1. Example of Link Stations 


and notification of link and link station failures to the ACF/VTAM operator. 
See ACF/NCP/VS (NCP-SSP) Installation and ACF/VTAM Planning and 
Installation Reference for more information. 


Cross-subarea links and link stations can be activated in one of several ways, as 
listed in the next paragraph. The examples that follow refer to Figure 1-1. 
The initial conditions are that ACF/VTAM and NCP1 are active, and that 
LINK1, LINKSTA1, and NCP2 are all inactive. Also assume that SDLC 
monitor mode has been specified in NCP2 for LINK2. 


As a result of a VARY ACT command, a link or link station can be activated: 


Directly by ACF/VTAM, as a result of a VARY ACT command naming the 
individual link or link station. An example of direct activation is when the 
ACF/VTAM operator enters separate commands to activate LINK1 and 
LINKSTA1. 


Indirectly by ACF/VTAM, as a result of a VARY ACT command. naming 
another resource to which the link or link station is subordinate. An 
example of indirect activation is when the ACF/VTAM operator enters the 
command VARY NET,ACT,ID=NCP1, SCOPE=U. ACF/VTAM 
activates LINK1 and LINKSTA1 if the definition statements for NCP1 
specified that LINK1 and LINKSTAI are to be initially active. Another 
example is when the operator enters the command VARY 
NET,ACT,ID=NCP1,SCOPE=ALL. ACF/VTAM activates all of the 
resources within NCP1, including LINK1 and LINKSTAI. 
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Routes 


Automatically by ACF/VTAM, as a result of a VARY ACT command 
naming an NCP adjacent to the link and link station. ACF/VTAM allows 
one channel link station and up to 13 SDLC link stations to be specified for 
automatic activation in an NCP definition or in the U and RNAME 
operands of the VARY ACT command for an NCP. An example of 
automatic activation is when the ACF/VTAM operator enters the command 
VARY NET,ACT,ID=NCP1,U=0C2. ACF/VTAM automatically activates 
the channel link 0C2-L and the channel link station 0C2-S. Similarly, if the 
operator enters the command VARY NET,ACT,ID=NCP2,RNAME= 
LINKSTA1, ACF/VTAM automatically activates the SDLC link LINK1 
and the SDLC link station LINKSTA1. 


By an NCP, using SDLC monitor mode. In the configuration shown in 
Figure 1-1, LINK2 must be defined to use SDLC monitor mode in order to 
allow ACF/VTAM to activate NCP2. NCP2 begins trying to activate 
LINK2 and LINKSTA2 as soon as NCP2 is loaded into its communication 
controller. When ACF/VTAM attempts to activate LINKSTA1 in NCP1, 
the monitor mode activation of LINKSTA2 completes along with the 
activation of LINKSTA1. ACF/VTAM is then able to communicate with 
NCP2 and activate it, if desired. 


For each of the types of activation performed by ACF/VTAM, there is a 
similar type of deactivation. That is, link and link station deactivation can be 
direct, indirect, or automatic. 


Any links or link stations that are automatically activated (and not also directly 
or indirectly activated) are automatically deactivated when they are no longer 
needed. In terms of the examples of automatic activation described above, 
LINK1 and LINKSTAI1 are automatically deactivated when NCP2 is 
deactivated, and 0C2-L and 0C2-S are automatically deactivated when NCP1 is 
deactivated. Links or link stations that are directly or indirectly activated are 
never automatically deactivated and remain active until they are dircctly or 
indirectly deactivated with ACF/VTAM operator commands. 


Channel links and link stations cannot be directly or indirectly activated; they 
can only be automatically activated. However, channel links and link stations 
can be displayed and deactivated with ACF/VTAM commands. If the channel. 
device name for a channel-attached communication controller is not supplied in 
the NCP definition, it must be supplied with the U operand of the VARY ACT 
command in order to use the channel connection. 


Migration Considerations: The SDLC monitor mode facility is not available in 
ACF/NCP/VS Release 2. In those configurations where SDLC monitor mode 
is required, ACF/NCP/VS Release 2 has a facility to allow activation of the 
NCP by ACF/VTAM. The use of this facility does not need to be specified in 
the definition of an ACF/NCP/VS Release 2. 


Before a session can be established between two subareas, there must be a 


defined operative route connecting the subareas. The routes are defined in path 


definition sets. A route becomes operative when all of the physical elements 
(host nodes, NCP nodes, transmission groups) included in the route are active. 


The operator should be aware that there are two logical levels of routes: 
explicit routes and virtual routes. 


Session Establishment 


Identification of Major 


An explicit route is an ordered set of transmission groups connecting two 
subareas. There can be up to eight explicit routes between any two subareas. 


A virtual route is a logical connection between two subareas. Each virtual route 
is assigned to an explicit route; more than one virtual route can be assigned to a 
given explicit route. A virtual route assumes the characteristics (sucn as the 
bandwidth and transmission rate) of the explicit route to which it is assigned. 


For more information on defining connectivity and routes, see the ACF/VTAM 
Planning and Installation Reference manual. 


Session establishment is the process of making a logical connection between two 
logical units so they can communicate with each other. Although sessions are 
usually initiated by logical units, activation of the resources in the path for the 
session is normally the operator’s responsibility and is handled by using 
ACF/VTAM operator commands. 


The operator must ensure that the two logical units are active, along with any 
links, link stations, physical units, or NCPs in the path. For example, suppose a 
terminal user at a terminal named T1234 wants to have a session with an 
application program called PAYROLL. Before this session can be started, the 
ACF/VTAM operator must: 


1. If T1234 and PAYROLL are not in the same subarea, ensure that a route is 
defined between their subareas (if not, activate the appropriate path 
definition set) and ensure that the links, link stations, and subarea nodes 
that make up the route are active. 


2. Activate the application program major node that contains the application 
program PAYROLL, activate PAYROLL, and start the PAYROLL job. 


3. Activate the major node that contains the logical unit definition for the 
terminal T1234. Ensure that the physical unit and logical unit for T1234 
are active. 


and Minor Nodes 


Each major and minor node has a name assigned to it. For example, 
PAYROLL can be the name assigned to an ACF/VTAM application program, 
and T1234 can be the name assigned to one of the domain’s device-type logical 
units (that is, a terminal). These names are assigned when the system 
programmer writes definition statements to define the logical units represented 
by the names PAYROLL and T1234. These statements contain control 
information and information about the characteristics of PAYROLL and 71234. 


The statements are filed as members of the VTAMLST data set (for OS/VS) or 
books in the source statement library (for VSE systems). The names of the 
major nodes are the names of the books or members, and the names of the 
minor nodes are the Jabels (for example, PAYROLL and T1234) of the minor 
node definition statements in the books or members. Thus, when an 
ACF/VTAM operator command is entered that contains a reference to the 
name of a book or member that defines an application program major node, for 
example, ACF/VTAM uses the contents of that book or member to determine 


_ the characteristics of that application program major node. 
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To control the major and minor nodes in a communication path (through 
activation or deactivation), the operator needs to know not only the names of 
individual major and minor nodes, but also their place within the resource 
hierarchy. For example, if one knows that T1234 represents a logical unit 
attached over a communication line, one also knows that it is a minor node 
subordinate to physical unit and line minor nodes and to an NCP major node. 


In this manual, the term physical unit. includes BSC 3270 cluster controllers 
attached to an NCP by a line defined with the PU=YES option. The term 
logical unit includes BSC 3270 terminals attached to such cluster controllers. 


Initial Configuration and Control 


The system programmer can use ACF/VTAM start options for initial 
configuration and control. Lists of start options can be filed away for future 
use. The options stored in these lists are then retrieved and processed when 
ACF/VTAM is started. In addition, the ACF/VTAM operator might be 
required to enter changes or additions to the options at the system console. If 
so, the system programmer should give the operator guidance on which options 
to enter. 


In OS/VS, the operator can enter start options on the START command or the 
system programmer can arrange to have ACF/VTAM prompt the ACF/VTAM 
operator for start options. 


In VSE systems, the operator can enter start options only when prompted for 
them by ACF/VTAM, so if the operator is required to enter start options, the 
system programmer must have made arrangements for prompting. For more 
information, see the ACF/VTAM Planning and Installation Reference manual. 


ACF/VTAM Commands 


ACF/VTAM is started and controlled with these commands: EXEC (to start 
ACF/VTAM in VSE), START (to start ACF/VTAM in OS/VS), VARY, 
MODIFY, DISPLAY, and HALT. Incorrect commands are rejected by 
ACF/VTAM’s command processor, and a message indicating the error is 
written to the ACF/VTAM operator. 


| The major use of the VARY command is to activate and deactivate major and 

, minor nodes. Some other uses of the VARY command are to terminate LU-LU 
sessions, acquire and release NCP major nodes, and to dynamically reconfigure 
‘ an NCP major node. 


| The major use of the MODIFY command is to change some of the operating 
|| parameters of ACF/VTAM. For example, the MODIFY command can be used 
' to start or stop traces or change the level of ACF/VTAM message suppression. 


To determine whether a minor node in an active major node is active or 
inactive, the ACF/VTAM operator can display its status by using a suitable 
DISPLAY command. If desired, the operator can also request in the same 
command a display of the names and status of certain other related minor 
nodes. For example, in the command to display the status of an application 
program, the names of other logical units that are currently in session with the 
application program can also be requested. 


Finally, ACF/VTAM provides a HALT command. The HALT command closes 
down the entire domain by deactivating all of its major and minor nodes and then 
stopping ACF/VTAM. 


In this manual these commands are referred to by a combination of the name of 
the major command (such as VARY) and the name of the principal operand used 
for a particular task. For example, the command used for activating a major node 
is referred to as a :q. VARY ACT command:eq. because the ACT operand of the 
VARY command is the principal operand for this task. 


Multiple-Domain Networks | | 
The optional Multisystem Networking Facility enables an ACF/VTAM domain to 
be part of a multiple-domain network. A multiple-domain network is a set of 
connected domains. Each domain is controlled by an ACF/VTAM, 
ACF/VTAME, or ACF /TCAM that has a cross-domain resource manager 
(CDRM). Before a logical unit in one domain can communicate with a logical 
unit in another domain, the CDRMs must be in session with each other. 


In a multiple-domain network, coordination of domain operators in different 
domains is required to permit cross-domain operations; domain operators can 
monitor and control only their own domain. A program operator can 
communicate with a program operator in another domain to request contro! across 
domain boundaries. For example, the Network Communications Control Facility 
(NCCF) has facilities that allow communication with a program operator in 
another domain. 
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Chapter 2. Operating ACF/VTAM 


This chapter describes the tasks involved in controlling an ACF/VTAM domain. 
It provides a general description of the kinds of tasks that operators perform, 
such as starting and halting ACF/VTAM, controlling ACF/VTAM resources, 
and monitoring the ACF/VTAM domain. These tasks are organized into 
roughly the same order in which an operator would perform them. The 
descriptions of some of the less frequently performed tasks, such as using 
diagnostic facilities and various miscellaneous ACF/VTAM facilities, are at the 
end of the chapter. 


For each task, the description gives: 


« A general idea of when and why the task is done 
e The commands to be used for a given task 


e Special considerations and potential problems, if any 


Starting ACF /VTAM 


Starting ACF/VTAM causes ACF/VTAM to be initialized. This can include 
the activation of some or all of the resources within the ACF/VTAM domain. 
It can also include selecting the optional ACF /VTAM facilities that are to be 
used. 


General Procedures 
The operator starts ACF/VTAM by: 


1. Making available channel-attached devices needed at start time 


2. Using the ACF/VTAM start procedure or entering the ACF/VITAM job 
control language statements 


3. Entering ACF/VTAM start options, if necessary 
Start Options 


At the time ACF/VTAM is started, start options are provided by a predefined 
start option list that was generated by the system programmer, by the 
ACF/VTAM operator, or both. The conditions established by the start options 
go into effect when ACF/VTAM is started and remain in effect until altered py 
the operator or until ACF/VTAM is halted. 


Using a predefined start option list simplifies the start procedure and reduces 
the chance that the wrong start options will be entered. ACF/VTAM 
automatically processes the start options in the default start option list 
(ATCSTROO) first. If this list is complete, and no changes or additions are 
needed, the operator need only enter the command to start ACF/VTAM. If 
changes are desired, the operator can provide them as described below: 


« In OS/VS systems, the operator can enter start options as part of the 


START command. If no start options are entered with the SVART 
command, the operator is prompted for start options, unless the system 
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programmer has specified NOPROMPT in the ATCSTROO list. If any of 
the options (from either a prestored list or the ones that the operator 
entered) are in error, the operator is prompted to enter correct start 
options, even if NOPROMPT is specified. 


e In VSE systems, the operator can enter start options only if prompted or if 
any of the options from either a prestored list or the ones that the operator 
entered are in error. The system programmer indicates that the operator is 
to be prompted by not specifying NOPROMPT in the ATCSTROO list. 


To override some or all of the options specified in the ATCSTROO list with 
those specified in another list, the operator can enter the LIST option for the 
prestored ATCSTRxx list that is to be used (where xx is the value specified for 
the LIST option). Any other options that the operator enters (in addition to 
the LIST option) are treated as changes or additions to the group of options 
that result after the processing of ATCSTROO first, and then ATCSTRxx. That 
is, the options in ATCSTRxx override those in ATCSTROO, and the options 
specified by the operator override those in ATCSTRxx. If the LIST option is 
not one of the options entered, the options specified by the operator are treated 
as changes or additions to ATCSTROO. 


To summarize, ACF/VTAM processes start options in the following order: 


1. The ATCSTROO options are processed. 


2. If the operator has entered the LIST=xx option, ACF/VTAM processes the 
ATCSTRxx options. 


3. If the operator enters other start options, ACF/VTAM processes those 
options. 


4. If there are errors in any of the prestored options or in any of the options 
entered by the operator, the operator is prompted to reenter those that are 
in error (even if NOPROMPT was specified). 


The specification last entered always overrides any previous specification if 
conflicting specifications exist for a particular option. For example, if 
ATCSTROO contains the option TRACE,TYPE=IO,ID=VTAM, but the 
operator specifies NOTRACE,TYPE=IO, the trace is not started during 
initialization. Additionally, if the same option appears more than once in the 
same prestored list or in the same group of operator entries at the console, the 
value for the last option entered takes effect. 


When all of the options have been accepted, ACF/VTAM begins processing 
them. Messages are displayed to tell the operator which nodes have been 
activated. Start processing continues until the message “VWTAM 
INITIALIZATION COMPLETE?” is received. Note that the initial activation of 
resources is independent of ACF/VTAM initialization (and the above message), 
so these activations will probably be continuing after this message is received. 
At this point, however, the ACF/VTAM operator command facilities are 
available to the operator and application programs can open their ACBs. 


From this point on, the job of the ACF/VTAM operator is to control and 
monitor the domain according to the procedures defined by the system 
programmer. 


Configuration Lists 


The system programmer can greatly reduce the ACF/VTAM operator’s start 
time workload by creating one or more configuration lists. These lists specify 
the major nodes and path definition sets that are to be activated when 
ACF/VTAM is started. Activating these resources with a configuration list 
eliminates the need for the operator to enter VARY ACT commands for them. 
The configuration list to be used when starting ACF/VTAM is specified with 
the CONFIG start option. For more information on creating and using 
configuration lists, see the ACF/VTAM Planning and Installation Reference 
manual. 


OS/VS Considerations 


The steps below outline additional considerations for starting ACF/VTAM in 
OS/VS systems. Specific start options and JCL must be supplied by the system 
programmer. : 


1. If the system programmer wants to use the resident ERP option with an 
alternate ERP list, the operator must respond to message IEA101A during 
operating system IPL by entering RERP=xx, where xx where xx represents 
the last two characters of the alternate ERP list’s name. These two 
characters should be supplied by the system programmer. For more 
information on the resident ERP option, see the ACF/VTAM Planning and 
Installation Reference manual. 


2. Use the OS/VS VARY command to make available the channel-attached 
devices needed at start time. 


3. If the Encrypt/Decrypt Feature is to be used, activate the IBM Programmed 
Cryptographic Facility Program Product. 


4. Use the START command to start ACF/VTAM. 
Multiple Console Support in ACF/VTAM 


ACF/VTAM commands can be entered and messages received by an operator 
at the system master console and at designated secondary consoles. 


To enter ACF/VTAM commands at a secondary console, the console must be 
authorized to accept commands from Command Group 1 (System Control 
Group) and Command Group 2 (I/O Control Group). An ACF/VTAM 
command response goes to the console at which the command was entered. 
Depending on their contents, ACF/VTAM messages use routing codes 1, 2, 4, 
6, 8, and 10. Therefore, a secondary console should be assigned routing codes 
based on the kinds of ACF/VTAM messages that are to be routed to that 
console. To determine the routing codes used by particular messages for 
OS/VS1 and OS/VS2 (MVS), see the ACF/VTAM Messages and Codes 
manual. 


Command authorization and message routing can be changed using the OS/VS 
VARY command. The following command, for example, designates a secondary 
console at which any ACF/VTAM command can be entered and at which any 
ACF/VTAM message that has not been suppressed can be received: 


VARY 01F,CONSOLE,AUTH=(SYS,IO) 
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VSE Considerations 


Configuration Restart 


The channel device name of the console is 01F. It is authorized to enter 
commands from Command Group 1 (SYS) and Command Group 2 (IO). This 
console will receive all messages that have not been suppressed. 


Details about using the OS/VS VARY command to designate a secondary 
console are contained in the system operator’s reference manuals for OS/VS1 
and OS/VS2 (MVS). 


The steps below outline additional considerations for starting ACF/VTAM in 
VSE systems. Specific partition assignments, JCL, and start options should be 
supplied by the system programmer. : 


1. Use the VSE system ADD command to make available the channel-attached 
devices needed at start time. 


2. Use the START command to start the partition in which ACF/VTAM is to 
run. 


3. Enter the JCL statements for starting ACF/VTAM, either from the system 
console or from a device to which SYSRDR has been assigned. The JCL. 
can be entered as separate statements from an input device, or the 
statements can be filed in the procedure library and invoked by entering the 
EXEC command from the console or from a device to which SYSRDR has 
been assigned. See VSE/AF Operating Procedures for details on filing and 
using a procedure, and for specifying modifications to a prestored 
procedure. For JCL examples, see the ACF/VTAM gL and 
Installation Reference manual. 


4. Certain IBM-supplied programs can be attached as ACF/VTAM subtasks 
with the MODIFY ATTACH command. 


Configuration restart is an optional facility that enables ACF/VTAM to 
maintain operator-modified status information about most ACF/VTAM 
resources. This information can be used when starting ACF/VTAM to 
automatically restore such checkpointed operator changes to some or all of the 
applicable resources in the domain. A major use of configuration restart is for 
backup and recovery. More information about configuration restart can be 
found in Chapter 3 of this book and in the ACF/VTAM Planning and 
Installation Reference manual. | 


Controiling the ACF/VTAM Domain With the Help of 


Application Programs 


Special application programs can be used to assist the ACF/VTAM operator in 
running an ACF/VTAM domain. Such an application program is either a 
program operator or a communication network management (CNM) application 
program. 


ACF/VTAM Resource 


A program operator is an application program that,is authorized to issue certain 
ACF/VTAM commands and receive ACF/VTAM messages. This facility can 
be used to: 


e Enter ACF/VTAM commands (except for commands to start or halt 
ACF/VTAM) from a terminal in the domain. 


e Monitor and control elements in the domain at program execution speed. 


e Define specialized commands (for example, to display the status of the 
entire domain). 


« Reformat responses to ACF/VTAM commands (such as to reformat the 
status display of the entire domain to fit on a 3270 display screen). 


ACF/VTAM Programming has a detailed description of the macro instructions 
used to create a program operator. An IBM program product, the Network 
Communications Control Facility (NCCF), can be used as a program operator. 
For information on NCCF, see Network Communications Control Facility 
General Information. 


A communication network management (CNM) application program can request 
and receive information that might be useful in managing an SNA network. 

The application program can communicate with certain physical units in the 
network to obtain status information. For more information on coding an 
application program that uses these facilities, as well as on what information can 
be obtained, see ACF/VTAM Programming. For information on ACF/VTAM 
definition requirements, see the ACK /VTAM Planning and Installation 
Reference manual. The NCCF program product can also be used as a 
communication network management application program. 


Hierarchy 


One of the main jobs of the operator of an ACF/VTAM domain is to control 


the use of ACF/VTAM resources (application programs, terminals, 


communication lines, and so on). The primary means of control is by activation 
(to make them available for use) and deactivation (to make them unavailable}. 


The resources of an ACF/VTAM domain are organized into a resource 
hierarchy. This hierarchy determines the scope of effect of ACF/VTAM 
operator commands. Within each major node, the major node itself is at the 
top of the hierarchy, followed by logically subordinate resources downto 
individual logical units (such as application programs and terminals). For a 
fuller explanation of the ACF/VTAM resource hierarchy, see ACF/VTAM 
Planning and Installation Reference. 


A resource cannot be activated unless all other resources above it in the 


hierarchy have been activated. For example, a logical unit cannot be activated 


unless the physical unit to which it is subordinate is already active. When a 
resource is activated, the resources below it in the hierarchy might be activated 
also, depending on the use of the SCOPE operand of the activation command, 
and on the definitions of the subordinate resources. (This is called indirect 
activation of the subordinate resources.) When a resource is deactivated, all of 


the resources below it in the hierarchy are also deactivated. (This is called 


indirect deactivation of the subordinate resources.) 
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While there is no logical hierarchy within the set of major nodes themselves or 
between resources in different major nodes, there is an obvious topological 
relationship among those major nodes representing subarea nodes in the 
network and those lines and link stations connecting them. Therefore, the 
activation of an NCP major node depends on having active the lines, link 
Stations, and other subarea nodes that constitute the routes between 
ACF/VTAM and the NCP. Likewise, deactivation of an NCP major node or a 
line or link station within it could have an effect on those other subarea nodes 
for which the resource being deactivated constitutes a part of the path from 
ACF/VTAM. 


In most cases, resources are activated either as part of ACF/VTAM start 
processing or as the result of a VARY ACT command. Resources can also be 
activated as a result of the VARY ACQ command (described in Chapter 3), or 
the VARY DRDS command (see “Dynamic Reconfiguration of an NCP” in this 
chapter). 


The CONFIG start option can be used to identify a list of the major nodes, 
path definition sets, and dynamic reconfiguration files that are to be activated 
by ACF/VTAM when it is started. Within the major nodes and dynamic 
reconfiguration files, any resources that are defined to be initially active are also 
activated. 


To activate a major node after ACF/VTAM is started, enter a VARY ACT 
command with the ID operand specifying the name of the node to be activated. 
After a major node is active, any of its subordinate resources that are still 
inactive can be activated with VARY ACT commands. The system programmer 
can request the indirect activation of any minor node through 
explicitly-specified or default values of the ISTATUS operand in the resource’s 
definition statement. This operand specifies that the resource is to be initially 
active; that is, it is to be activated when the resource to which it is subordinate 
is activated. When activating a resource with a VARY ACT or VARY ACQ 
commands, the SCOPE operand can be used to control the indirect activation of 
the subordinate resources. 


As introduced in the discussion above, a resource can be activated either 
directly or indirectly by ACF/VTAM. Direct activation is when the operator 
enters a command to activate a particular resource, and indirect activation is 
when a resource is activated as a result of the activation of another resource to 
which it is subordinate. For example, the operator can directly activate a 
physical unit by entering a VARY ACT command that specifically names that 
physical unit, or the operator can indirectly activate the physical unit by 
entering a command to activate the line to which the physical unit is 
subordinate, provided that the operator specifies SCOPE=ALL or SCOPE=U 
on the VARY ACT command. (For SCOPE=U, the definition statement for 
the physical unit must specify that the physical unit is to be initially active.) 


In addition, a VARY ACT command for a subarea node (that-is, an NCP) can 
result in the automatic activation of cross-subarea links and link stations in 
adjacent subarea nodes (other NCPs or ACF/VTAM itself). For example, if 
the operator enters a command to activate an NCP, ACF/VTAM automatically 
activates the link stations in adjacent nodes that are known to be needed for the 
connection to the NCP being activated. ACF/VTAM can know this from the 


channel device name or RNAME specification (or both) of either the NCP 
definition statement or the VARY ACT command. 


Activating a node causes different actions by ACF/VTAM depending upon the 
node type. Sometimes activation involves sending commands to the node, but 
in some cases activation is just a logical operation to make the nodes available 
for subsequent operations (as in the case of switched physical unit minor 
nodes). 


Order of Activation 


All of the elements of a communication path between two session end points 
must be active before a session can be established. In domains with more than 
one subarea, or in multiple-domain networks, a path definition set must be 
activated before communication between subareas is attempted. Major nodes 
are activated, and then their minor nodes are activated to enable sessions to be 
established for carrying user message traffic. 


While an activation command for a major node can be entered al any time after 
ACF/VTAM is initialized and before it is halted, the activation of subarea 
nodes (that is, NCP major nodes) and external CDRM minor nodes require 
fully operative explicit routes in order to proceed. If such routes are not 
available, the activations remain pending until the routes become available or 
until the operator deactivates the resources. 


Before a minor node can be activated, the major node and all minor nodes to 
which it is subordinate must be activated. 


If automatic logons to a controlling application program have been defined for 
any logical units, ensure that all of the necessary application program major 
nodes have been activated before activating (directly or indirectly) any of these 
logical units. | 


In a multiple-domain network, the host CDRM (the CDRM that represents the 
ACF/VTAM SSCP) must be active before any external CDRM is activated. 


Deactivating Resources 


The operator deactivates ACF/VTAM resources with a VARY INACT 
command. Resources can also be deactivated as a result of the VARY REL 
command (described in Chapter 3). 


ACF/VTAM deactivates resources in the opposite order from activation. When 
ACF/VTAM receives a command to deactivate a resource, it first deactivates 
any resources subordinate to the named resource, moving from the bottom of 
the hierarchy upward, and then deactivates the named resource. 


As with activation, a resource can be deactivated either directly or indirectly by 
ACF/VTAM. Direct deactivation is when the operator enters a command to 
deactivate a particular resource, and indirect deactivation is when a resource is 
deactivated as a result of the deactivation of another resource to which it is 
subordinate. For example, the operator can directly deactivate a physical unit 
by entering a VARY INACT command that specifically names that physical 
unit, or the operator can indirectly deactivate the physical unit by entering a 
command to deactivate the line (or any other resource) to which the physical 
‘unit is subordinate. 
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In addition, a VARY INACT command for a subarea node (that is, an NCP) 
can result in the automatic deactivation of cross-subarea links and link stations | 
in adjacent subarea nodes (other NCPs or ACF/VTAM itself). For example, if 
the operator enters a command to deactivate an NCP, ACF/VTAM 
automatically deactivates any links and link stations that were automatically 
activated in adjacent nodes provided these adjacent links and link stations were 
not also directly or indirectly activated. 


Besides the types of deactivation described previously, in which deactivation is 
classified by relations between types of resources according to their places in 
resource or topological hierarchies, there are other types of deactivation within a 
classification based on the “strength” of the VARY INACT command as 
specified by the operator. When entering a VARY INACT command, the 
operator can specify normal deactivation, immediate deactivation, forced 
deactivation, or forced reactivation. 


Normal deactivation is the default for the VARY INACT command. When 
normal deactivation is requested, resources are not actually deactivated by 
ACF/VTAM until LU-to-LU sessions associated with the resources have been 
terminated. All queued requests for sessions involving the resources to be 
deactivated are discarded and the initiators are notified. No new requests for 
sessions with these resources are accepted. An application program in session 
with a logical unit to be deactivated is not notified of pending normal 
deactivations. 


Immediate deactivation is specified with the I operand of the VARY INACT 
command. When immediate deactivation is requested, LU-to-LU sessions 
associated with the resources are effectively broken. All queued requests for 
sessions involving the resources to be deactivated are discarded and the 
initiators are notified. No new requests for sessions involving these resources 
are accepted. All input and output operations for active LU-to-LU sessions are 
immediately halted, with possible loss of data. If the deactivation is of a logical 
unit in session with an application program, the application program is notified 
of the deactivation. The application program must complete the session 
termination for the deactivation to be completed. 


Immediate deactivation provides tight control over the domain; normal 
deactivation provides less stringent control, but allows for a more orderly 
deactivation. Normal and immediate deactivations are not completed until the 
proper SNA commands and responses are exchanged between the ACF/VTAM 
SSCP and the affected resources. If conditions in the domain prevent the 
sending of the proper commands or responses, normal and immediate 
deactivation might not be successful. 


Forced deactivation is specified with the F operand of the VARY INACT 
command. When forced deactivation is requested, all of the actions described 
for immediate deactivation apply and, in addition, ACF/VTAM deactivates the 
resources internally, without waiting for responses to deactivation commands. 
An application program notified of the termination of a session with a 
deactivated logical unit might have to complete the session termination 
(depending on how the application program is coded) for the deactivation to be 


completed. Forced deactivation can be used when immediate and normal 


deactivation are not successful. 


Forced deactivation does not apply to all types of resources. The description of 
the VARY INACT command in Chapter 4 contains a table that lists the 
resources to which forced deactivation applies. This table also indicates what 
ACF/VTAM does if forced deactivation is requested for a resource to which it 
does not apply. 


Forced reactivation is specified with the R operand of the VARY INACT 
command. When forced reactivation is requested, ACF/VTAM performs a 
forced deactivation (except that for certain resource types it does wait for 
command responses from the resource) and then attempts to reactivate the 
resource. Forced reactivation of an NCP reactivates the SSCP-to-NCP session, 
but has no effect on links and link stations in adjacent subarea nodes. (In this 
case the forced reactivation command should be entered for the adjacent link or 
link station if one of these resources is the source of the problem.) 


Forced reactivation does not apply to all types of resources. The description of 
the VARY INACT command in Chapter 4 contains a table that lists the 
resources to which forced reactivation applies. This table also indicates what 
ACE/VTAM does if forced reactivation is specified for a resource to which it 
does not apply. 


Order of Deactivation 


Deactivation of certain ACF/VTAM resources requires more attention from the 
operator than does their activation. The operator must be concerned about the 
changing shape of the domain and the effects of NCP and cross-subarea link 
and link station deactivations on the operation of the rest of the network. In 
particular, the operator should be careful not to deactivate an NCP through 
which other NCPs are attached to the network, or a link or link station that 
provides the only connection between a subarea and the rest of the network. 
For more information, see the following section on the special considerations for 
links, link stations, and NCP major nodes. 


Special Considerations for Controlling Each Resource Type 


The following sections describe the operating considerations for each of the 
major types of resources. 


Path Definition Sets 


In an ACF/VTAM domain that has more than one subarea and in a 
multiple-domain network, ACF/VTAM must have a description of the routes 
connecting the subareas. ACF/VTAM requires the activation of one or more 
path definition sets in order to know how to route cross-subarca session traffic. 


A route becomes defined (but not actually active) when a path definition set is 
activated with a VARY ACT command. When necessary, the operator can 
activate additional path definition sets to add or modify the route definitions. 
The operator can define new routes or redefine inactive routes. Existing route 
definitions not affected by a given path definition set activation are unmodified 
and remain in effect. ACF/VTAM rejects any attempt to modify the definition 
of any previously-defined route that is not in the “inactive” state. 


A path definition set is not a major node and cannot be deactivated. 
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An explicit route becomes available for activation after it is defined by 
activation of a path definition set and when all of the physical elements (host 


nodes, NCP nodes, and transmission groups) included in the explicit route are 
active. A virtual route becomes available for activation after its corresponding 
explicit route is active. ACF/VTAM automatically activates explicit routes and 
virtual routes as they are required for sessions. ACF/VTAM selects a virtual 
route for a session based on a class of service list that is defined by the system 
programmer, as described in the ACF/VTAM Planning and Installation 
Reference manual. A virtual route remains active until all sessions assigned to it 
have ended, at which time it is automatically deactivated. Once active, an 
explicit route remains active as long as all the physical elements that make up 
the explicit route are active. 


While operators do not activate or deactivate routes of either kind, they do 
activate and deactivate the physical elements that make up explicit routes. They 
do this by activating or deactivating the major and minor nodes that define the 
physical elements. 


The DISPLAY ROUTE command can be used to display information about the 
explicit routes and virtual routes between the host subarea and a given 
destination subarea. This command can also be used to test whether one or 
more explicit routes to a given destination are operative (see “Route 
Verification” in Chapter 3). 


Before an application program can use ACF/VTAM services, its application 
program minor node must be active and the job representing the application 
program must be started. The minor node can be activated directly with the 
VARY ACT command or indirectly through activation of its major node. The 
application program job is started like any other job in the system. After an 
application program minor node is activated, it is up to the application program . 


to open its ACB and begin using ACF/VTAM services. The order in which the 


minor node is activated and the application job is started is not critical, but the 
minor node must be active when the application program attempts to open its 
ACB for ACF/VTAM. 


To enable the ACF/VTAM application programs to handle automatic logon 
requests, all of the necessary application program major nodes must be activated 
before activating (directly or indirectly) any logical units with automatic logon 
specifications. The necessary application program major nodes are those that 
contain the application programs for which an automatic logon request can be 
generated. | 


If the operator cancels an application program, the operating system forces the 
application program’s disconnection from ACF/VTAM. For the operator to be 
able to cancel an application program that is active to ACF/VTAM, the 
operator must be able to associate the application program’s ACF/VTAM name 
with the application program’s job name. | 


TSO/VTAM operators should never use the VARY INACT command to 
deactivate a TSO user address space application name while TSO/VTAM is 
operating. | | 


Changing the Automatic Logon Specification for a Logical Unit 


When defining the domain, the system programmer can specify that a 
device-type logical unit is to be automatically logged on to a particular 
application program whenever the logical unit is available for a session. Such an 
application program is called a controlling application for that logical unit. It is 
the responsibility of the application program to accept or reject the logon 
request. The ACF/VTAM operator can use the VARY LOGON command, or 
the LOGON operand of the VARY ACQ or VARY ACT commands, to change 
an existing automatic logon specification or to create an automatic logon 
specification where one does not exist. 


Operator-initiated automatic logons apply to any device-type logical unit. 
Neither the logical unit nor the application program need be active when the 
operator command is entered. However, the major nodes for the logical unit 
and the application program must both be active. 


An automatic logon specification remains in effect until another VARY 
LOGON, VARY ACO,LOGON, or VARY ACT,LOGON command is entered 
for the logical unit, or until the major node containing the logical unit is 
deactivated. For a logical unit that is currently in session or queued for a 
session, the logical unit is logged onto the specified application program 
whenever these sessions end. 


Channel-Attached SNA Devices 


When activating a physical unit in a local SNA major node, the operator will 
need to supply the channel device name of the physical unit unless the system 
programmer supplies it in the PU definition statement. The operator can also 
specify the channel device name to override the value in the PU definition. To 
supply the channel device name, use the U operand of the VARY ACT 
command when activating the physical unit. 


If ACF/VTAM needs the operator’s assistance in creating a connection to a 
physical unit in a local SNA major node, ACF/VTAM displays the message 
IST680I (OS/VS) or 5G80I (VSE). This message indicates that a connection 
request was denied because the physical unit is offline. The connection request 
remains pending and the operator should either allow the connection request to © 
complete by making the device available, or disallow the connection request by 
entering a VARY INOP command for the physical unit. 


Channel-Attached Non-SNA Devices 


The physical unit for a channel-attached non-SNA device is the ACF/VTAM 
physical unit (ISTPUS), which is always active while ACF/VTAM is running. 
Therefore, only the local non-SNA major node and its logical units 
(representing the channel-attached devices) need to be activated. 


The channel device name cannot be specified when activating the logical unit 
for a non-SNA device; the channel device name must be specified in the 
ACF/VTAM definition statement for the device. 


A local non-SNA major node should always be deactivated before taking its 
terminals offline. 
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There are two kinds of links in an ACF/VTAM domain: links between an NCP 
and its peripheral physical units, and cross-subarea links. There are no special 
considerations for activating the links between an NCP and its peripheral 
physical units. For cross-subarea links, however, there are various 
considerations, depending on whether they are channel links or SDLC links. 


Channel links are named by ACF/VTAM, which creates the name by taking 
the channel device name for the communication controller and adding “‘-L” to 
the end. For example, the channel device name 0C2 has the link name of 
0C2-L. Channel links can only be automatically activated; any VARY ACT 
command specifying a channel link is rejected. However, channel links can be 
deactivated directly, indirectly (by halting ACF/VTAM), or automatically. 


Using a VARY ACT command to directly or indirectly activate an SDLC link 
makes the link active to ACF/VTAM and, within the NCP containing the link, 
makes ACF/VTAM’s SSCP an owner of that link. For SDLC cross-subarea 
links, more than one SSCP can share ownership of a link if the link is activated 
by each SSCP. Such a link can also be active without SSCP ownership if it has 
been defined to use the SDLC monitor mode function in the NCP. As a result, 
a cross-subarea link can be capable of carrying session traffic without having 
been activated by ACF/VTAM. 


The NCP deactivates a link and its subordinate link station when the last of the 
link’s SSCP owners deactivates the link. When the last active link station in a 
transmission group is deactivated, any session traffic being carried by that 
transmission group is disrupted. Therefore, if the ACF/VTAM operator has 
not activated a cross-subarea link and ACF/VTAM is using that link’s 
transmission group to carry session traffic, those sessions are disrupted if the 
link’s owners all deactivate the link and there are no other active link stations in 
the transmission group. On the other hand, if the ACF/VTAM operator 
activates the link, ACF/VTAM shares in the ownership of the tink and the link 
remains active, regardless of the link deactivation requests of other domain 
operators. 


The same considerations apply when using the VARY INACT command to 
deactivate a link that is owned by ACF/VTAM. If ACF/VTAM is the sole 
owner of a link, and that link’s link station is the only active link station in a 
transmission group, deactivating that link destroys any sessions using a route 
containing that transmission group, possibly including the SSCP’s session with 
the NCP containing the link being deactivated. For this reason, care should be 
taken not to deactivate a cross-subarea link that could be supporting session 
traffic if its link station is the only link station in a transmission group and 
ACF/VTAM is sole owner of the link. 


The operator and, optionally, the system programmer, can prevent the automatic 
deactivation of cross-subarea links in adjacent subarea nodes when an NCP is 
deactivated. The system programmer (using the initial status specification in the 
link definitions) and the operator (using individual VARY ACT commands or 
VARY ACT with the SCOPE operand) can ensure that the links in adjacent 
nodes have been directly or indirectly activated before the NCP is deactivated. 


Deactivation of a cross-domain link also causes the deactivation of its 
subordinate link station. 


Link Stations 


As with cross-subarea links, there are both channel link stations and SDLC link 
stations. When a cross-subarea link station becomes active, ACF/VTAM issues 
a message to the operator indicating the name and subarea number of the 
adjacent subarea node with which contact has been established. 


Channel links stations are named by ACF/VTAM, which creates the name by 
taking the channel device name for the communication controller and adding 
‘*-S” to the end. For example, the channel device name OC2 has the link 
station name of 0C2-S. Channel link stations can only be automatically 
activated; any VARY ACT command specifying a channel link station is 
rejected. However, channel link stations can be deactivated directly, indirectly 
(by halting ACF/VTAM), or automatically. 


Using a VARY ACT command to directly or indirectly activate an SDI.C link 
station makes the link station active to ACF/VTAM and, within the NCP 
containing the link station, makes ACF/VTAM’s SSCP an owner of that link 
station. For cross-subarea link stations, more than one SSCP can share 
ownership of a link station if the link station is activated by each SSCP. Such a 
link station can also be active without SSCP ownership if its link has been 
defined to use the SDLC monitor mode function in the NCP. As a result, a 
cross-subarea link station can be capable of supporting session traffic without 
having been activated by ACF/VTAM. 


The NCP deactivates a link station (even if the associated link is currently 
carrying session traffic) when the last of the link station’s SSCP owners 
deactivates the station. When the last active link station in a transmission group 
is deactivated, any session traffic being carried by that transmission group is 
disrupted. Therefore,, if the ACF/VTAM operator has not activated a 
cross-subarea link station and ACF/VTAM is using that link station’s 
transmission group to support session traffic, those sessions are disrupted if the 
link station’s owners all deactivate the link station and there are no other active 
link stations in the transmission group. On the other hand, if the ACF/VTAM 
operator activates the link station, ACF/VTAM shares in the ownership of the 
link station and the link station remains active, regardless of the link station 
deactivation requests of other domain operators. 


The same considerations apply when using the VARY INACT command to 
deactivate a link station that is owned by ACF/VTAM. If ACF/VTAM is the 
sole owner of a link station, and that link station is the only active link station 
in a transmission group, deactivating that link station destroys any sessions 
using a route containing that transmission group, possibly including the SSCP’s 
session with the NCP containing the link station being deactivated. For this 
reason, care should be taken not to deactivate a cross-subarea link station that 
could be supporting session traffic if it is the only link station in a transmission 
group and ACF/VTAM is the sole owner of the station. 


The operator and, optionally, the system programmer, can prevent the automatic 
deactivation of cross-subarea link stations in adjacent subarea nodes when an 
NCP is deactivated. The system programmer (using the initial status 
specification in the link station definitions) and the operator (using individual 
VARY ACT commands cr VARY ACT with the SCOPE operand) can ensure 


- that the link stations in adjacent nodes have been directly or indirectly activated 


before the NCP is deactivated. 
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Migration Considerations: |When a cross-subarea link station in an 
ACF/NCP/VS Release 2 becomes active, or when a cross-subarea link station 
establishes contact with an adjacent ACF/NCP/VS Release 2, ACF/VTAM 
issues a message to the operator indicating only the subarea address of the 
contacted adjacent NCP. 


A cross-subarea link station defined within an ACF/NCP/VS Release 2 can be 
owned by only one SSCP. 


As previously discussed, there is no resource hierarchy among major nodes, and 
thus any NCP major node can be activated at any time. (There must be at least 
one defined route to the NCP, however. This requires that an appropriate path 
definition set be activated prior to the activation of the NCP.) An NCP 
activation remains pending until a route to the NCP becomes physically 
available. 


When activating an NCP, ACF/VTAM can be provided with a list of link 
stations in subarea nodes adjacent to the NCP that are to be automatically 
activated along with the NCP. These link stations, in combination with 
already-active link stations adjacent to the NCP, are the means by which the 
NCP is connected to the rest of the network. In addition to providing access to 
the NCP being activated, activating the link stations provides link station 
ownership (see ‘Link Stations” earlier in this chapter), whereby the 
ACF/VTAM SSCP is supplied with notification of link station failures by the 
NCP containing the link station. Activation of the link stations also provides 
the ability to dump or load the NCP through the link stations. 


The link stations that are to be automatically activated can be specified by the 
system programmer in the CUADDR and RNAME operands of the PCCU 
definition statement for the NCP (this method is recommended to simplify 
operating procedures and reduce the chance for operator error). If the system 
programmer has not specified these link stations, or if there is a need to 
override the defined link station names, the operator can use the U or RNAME 
operands (or both) on the VARY ACT command when activating the NCP. 


When the NCP is activated, the specified link stations and their associated links 
are automatically activated if they are not already active. If any of these link 
stations are not yet known to ACF/VTAM, (that is, if the NCP within which 
they are defined has not been activated), ACF/VTAM remembers them until 
they become known (through the activation of their major node) and then 
completes the activation. ACF/VTAM informs the operator of the link stations 
that are awaiting the activation of their NCP. 


Figure 2-1 shows an example of this process. Assume that NCP1 is active and 
that LINK1, LINKSTA1, and NCP2 are not. Also assume that when defining 
NCP2, the system programmer specified the link stations 0C2-S and LINKSTA1 
for automatic activation (by specifying CUADDR=0C2 and 
RNAME=LINKSTAI1). 


When the operator activates NCP2, ACF/VTAM automatically activates the 
channel link 0C2-L and its: link station OC2-S (enabling ACF/VTAM to 
communicate with NCP2 directly over the channel link), and also automatically 
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Figure 2-1. Activating an NCP 


activates the SDLC link LINK1 and its link station LINKSTAI1 (enabling 
ACF/VTAM to communicate with NCP2 through NCP1). 


If NCP1 were inactive when the operator tried to activate NCP2, the activation 
of LINK1 and LINKSTAI would be delayed until NCP1 was activated. 
ACF/VTAM would still be able to communicate with NCP2 through its 
channel connection. 


If ACF/VTAM must delay the activation of all of the link stations specified for 
automatic activation, and if there are no other active connections to the NCP 
being activated, the NCP activation itself is delayed to await the availablilty of 
an active connection. The operator should activate the adjacent NCPs 
containing the link stations to allow the original NCP activation to complete. 


Similarly, if none of the routes to an NCP being activated are physically 
available, ACF/VTAM displays a message to the operator and delays the 
activation of the NCP until at least one route becomes available. If a request is 
entered to activate an NCP to which no route has been defined, ACF/VTAM 
does not delay the activation; rather, the activation fails. 


Any suspended activation of an NCP or link station can be terminated by 
deactivating that NCP or link station. 


~ When ACF/VTAM automatically activates an adjacent link station during 
activation of an NCP, ACF/VTAM expects to find that the link station is 
connected to a communication controller that either requires loading of an NCP 
or that contains the NCP being activated. If, through an operator or system 
programmer error, the list of link stations to be automatically activated includes 
one or more link stations that are connected to the wrong communication 
controller, ACF/VTAM might not detect the error and could assume that this 
wrong communication controller is to be reloaded with the NCP being activated. 
Therefore, care should always be taken to ensure that link stations are correctly 
chosen for automatic activation with an NCP; specifically, that the link stations 
are in fact connected to the communication controller that does or should 
contain that NCP. | 
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Likewise, if the physical links to a communication controller running a given 
NCP are reconnected to a different communication controller (perhaps running 
another NCP), the link stations specified for automatic activation with the 
NCPs might need to be updated to reflect the new connections. That is, the 
CUADDR and RNAME values on the PCCU statement in the NCP definitions 
might need to be updated. (Alternatively, revised link station specifications 
could be supplied using the U and RNAME operands of the VARY ACT 
command.) Also, the WARM start option and the WARM operand of the 
VARY ACT command should be avoided when activating the affected NCPs if 
the link station specifications are changed. Failure to update the adjacent link 
station specifications might result in the activation or loading of the wrong 
communication controller when an NCP is activated. 


An NCP can be shared by more than one SSCP. A VARY ACT command for 
an NCP causes the ACF/VTAM SSCP to activate the NCP, establishing an 
SSCP-to-NCP session. If multiple SSCPs activate an NCP, each of those 
SSCPs established an SSCP-to-NCP session and each is considered an owner of 
that NCP. Each SSCP can also activate and share ownership of the NCP’s 
links and link stations (except that in ACF/NCP/VS Release 2, link stations 
cannot be shared). However, the NCP’s physical units and logical units can 
belong to only one SSCP at a time. Whichever SSCP activates a particular 
physical unit first becomes the exclusive owner of that physical unit; the other 
SSCP cannot activate it until the SSCP that currently owns the physical unit 
deactivates it. | 


Besides operational division of resources within an NCP as described above 


-(where the first operator to enter VARY ACT becomes the owner of a physical 


unit, for example), the unsharable resources of an NCP can also be explicitly 
divided among the SSCPs that own the NCP. The system programmer can use 
the OWNER operand in NCP definition statements to explicitly identify the 
SSCP that is to own a particular resource. If a resource is allocated to a 
particular SSCP by the OWNER operand, then that resource can be controlled 
only by operator commands entered from that SSCP. Therefore, VARY ACT 
and VARY INACT commands can be entered for these resources from the 
SSCP that owns them, but not from any of the other SSCPs that share the 
NCP. 


if the Multisystem Networking Facility is installed, the BACKUP operand can 
also be used in the NCP definition. The system programmer can use this 
operand to specify that the NCP’s resources can be taken over by a backup 
SSCP. The operator at a backup SSCP can enter a VARY ACQ command to 
acquire resources that belong to another SSCP. The VARY ACQ command 
makes available all of the NCP’s resources, regardless of how the OWNER 
operand is specified. The operator can return the resources by using the VARY 
REL command. 


Chapter 3 describes how to use NCP sharing and division of resources for 
backup and recovery in a multiple-domain network. See in particular 
“SSCP-to-NCP Session Failure’ and. “Resource Takeover Strategies.” The 
OWNER and BACKUP operands are described in the ACF/VTAM Planning 
and Installation Reference manual. | 


Loading an NCP into a Communication Controller 


The activation of an NCP could cause the NCP to be loaded into its designated 
communication controller. The communication controller is determined by the 
adjacent link stations specified for automatic activation with the NCP. (These 
link stations in adjacent nodes “locate” the communication controller in the 
network.) 


The operator can directly control whether the communication controller is 
loaded by using the LOAD operand of the VARY ACT command. The LOAD 
operand specifies one of the following: 


«e LOAD=YES--the communication controller is to be loaded, regardless of its 
current status or contents. 


e LOAD=NO--the communication controller is not to be loaded, regardless of 
its current status or contents. (This does not preclude a later reload of the 
communication controller [after NCP activation] as a result of error 
recovery procedures.) If the communication controller does not contain the 
expected NCP load module, the NCP activation fails. 


e LOAD=U--ACF/VTAM is to decide whether the communication controller 
is to be loaded. 


If ACF/VTAM is allowed to decide whether to reload the communication 
controller, one of the following occurs: 


« If the communication controller contains no program, ACF/VTAM loads 
the NCP into the communication controller. 


¢« If the communication controller already contains the NCP being activated, 
the operator might be asked whether the existing NCP should be refreshed 
with a new copy. If the system programmer specified AUTOSYN=NO on 
the PCCU macro in the NCP definition, ACF/VIAM does not 
automatically resynchronize itself with the existing NCP, but rather asks the 
operator whether resynchronization or reloading should occur. Otherwise, 
ACF/VTAM resynchronizes itself with the NCP without operator 
intervention and without reloading the communication controller. 


« If the communication controller contains an NCP other than the one being 
activated, the operator might be asked whether the existing NCP should be 
replaced. If the system programmer specified VFYLM=YES on the PCCU 
macro instruction in the NCP definition, the operator is asked to confirm 
that the communication controller should be reloaded. Otherwise, 
ACF/VTAM goes ahead with the reload without operator intervention. 


e If the communication controller contains a program other than an NCP (for 
example, an EP program in a channel-attached communication controller), 
the NCP activation fails when ACF/VTAM attempts to send the SNA 
ACTPU request. Another VARY ACT command specifying LOAD=YES 
can be entered to force loading of the NCP. 


Besides those considerations previously described, the operator should be aware 
of other considerations involved in activating an NCP in a communication 
controller that already contains a different NCP. The operator should first 
deactivate the current NCP (if it is not already inactive), and deactivate any 
active link stations in adjacent subarea nodes that are connected to that NCP. 
The operator can then enter the command to activate the new NCP, which 
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causes the communication controller to be reloaded as described above (if 
LOAD#=U is specified or assumed). If adjacent link stations are not 
deactivated, the activation of the new NCP might fail because: 


« There are no link stations available (ACF/ VTAM does not automatically 
break the existing connections with the old NCP). 


« The names of the old and new NCPs are the same, but their subarea 
addresses are different. 


« The subarea addresses of the old and new NCPs are the same, but their 
names are different. 


ACF/VTAM fails an NCP activation (instead of loading a fresh copy of the 
NCP) if the NCP rejects ACF/VTAM’s activation request. The operator can 
then investigate the cause of the failure, and force a reload of the NCP, if 
necessary. 


Within its domain, ACF/VTAM ensures that no more than one load or dump 
operation is attempted at one time for a given NCP through the various 
adjacent link stations that might be available. In a multiple-domain network, 
however, it is up to the individual domain operators to prevent simultaneous 
attempts to load or dump the same communication controller from different 
domains. 


For an additional discussion of loading and dumping NCPs, see “Dumping and 
Loading an NCP” in Chapter 3. 


Migration Considerations: When replacing an ACF/NCP/VS Release 2 with 
ACE/NCP/VS Release 3, the operator should force a reload of the 
communication controller. Unless this is done (or unless the Release 3 NCP 
has a different name and subarea number), ACF/VTAM will be misled into 
believing that a reload of the communication controller is not required. 


When loading an NCP, ACF/VTAM needs to know the name of the adjacent 
link station through which the load operation is to be carried out. The load 
station can be either a channel link station or an SDLC link station. 
ACF/VTAM can be allowed to select a load station, or the system programmer 
or the operator can specify a load station. The load station can be specified in 
the NCP definition, on the VARY ACT command, or during NCP error 
recovery if ACF/VTAM asks the operator whether the NCP should be 
reloaded. ACF/VTAM selects the load station whenever there is no load 
station name currently in effect from one of the above sources. 


When ACF/VTAM selects a load station, it selects a channel link station, if one 
is available. If no channel link station is available, ACF/VTAM uses any 
available SDLC link station. 


If the operator wants to override a load station name specified in an NCP 
definition, the LOADSTA operand of the VARY ACT command can be used to 
specify the name of another link station. This override capability can also be 
used to specify that ACF/VTAM should select the load station, despite the 
NCP definition. This is done by specifying a null value for the load station 
(that is, specifying LOADSTA without a value). If the operator chooses not to 


override the NCP definition value, ACF/VTAM uses that definition value to 
determine the link station to be used. 


A link station chosen as a load station must also be specified for automatic 
activation with the NCP, or must be already active when it is needed (with 
ACF/VTAM thus knowing of its connection to the NCP). The former method 
is recommended. If a specified load station is not available for a load operation 
resulting from a VARY ACT command, the command fails. If a specified load 
station is not available for a load operation resulting from error recovery 
procedures for an NCP, ACF/VTAM either prompts the operator for a link 
Station name or selects a link station from among those that are available, as 
described above. (See “Dumping and Loading an NCP” in Chapter 3 for 
details regarding NCP error recovery procedures.) 


As with the link stations specified for automatic activation with an NCP, care 
should be taken to avoid the error of naming a Jink station connected to some 
communication controller other than the intended one. Such an error might 
result in loading the wrong communication controller. Likewise, the 
reconnection of cross-subarea links from one communication controller to 
another might require the changing of load station specifications for those NCPs 
intended to run in the communication controllers. The WARM start option and 
the WARM operand of the VARY ACT command should be avoided when 
activating the affected NCPs if the load station specifications are changed. 


Note that improperly specified LOADSTA values for two or more NCPs can 
result in a deadlock during their activation, with the activation of each NCP’s 
load station waiting for the adjacent NCP’s activation, which in turn can be 
waiting the availability of a load station. 


Note also that any link to be used to load (or dump) a communication 
controller must be defined to both the NCP and the communication controller 
as being capable of initial program load (IPL). For the NCP, this is done by 
specifying IPL=YES on the LINE macro instruction in the NCP definition. For 
the communication controller, the ability of a link to accept an IPL is indicated 
in the configuration data set (CDS) residing in the communication controller’s 
diskette storage. Any attempt to load the communication controller over an 
SDLC link that is not so specified will fail (including an attempt resulting from 
the selection of an otherwise available SDLC link station by ACF/VTAM in 
the absence of a specific LOADSTA specification). 


Communication Controller Channel Enable Switches 


The channel-enable switches on a communication controller panel determine 
whether ACF/VTAM can activate a channel link and link station during an 
NCP activation. For a communication controller that is both channel- and 
SDLC-link-attached, these switches also determine whether an NCP can be 
loaded over a channel or an SDLC link. If any channel adapters are enabled on 
the communication controller, the Remote Program Load (RPL) feature of the 
communication controller is disabled, and the communication controller can be 
loaded only over one of these channels. If none of the channel adapters are 
enabled, the communication controller can be loaded only over SDLC links | 
defined as being capable of IPL (as described under “Selecting a Load 
Station’’). 
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All channel adapters should be kept enabled during normal operations with 
channel-attached NCPs. This is because a channel link station activation fails 
(with the channel appearing to be “not operational’’) if the channel adapter for 
the channel ACF/VTAM is attempting to use is disabled. ACF/VTAM does 
not recover the use of the channel (even if the channel adapter is later enabled) 
unless the NCP is deactivated and reactivated. By keeping all channel adapters 
enabled, the SDLC links are still available for normal use after the NCP is 
loaded or if the NCP was previously loaded. The channel enable switches 
should only be turned off when a communication controller must be loaded over 
an SDLC link (such as when the channel-attached host has failed along with the 
NCP). 


Figure 2-2 shows an example of an NCP that is both channel- and 
SDLC-link-attached to an ACF/VTAM host. For this example, assume that 
NCP1I is active and that NCP2 is inactive and requires loading of its NCP load 
module. 


The operator activates NCP2 as follows (with NCP2’s channel adapter enabled 
on the communication controller panel): 


VARY NET,ACT,ID=NCP2,U=0C2,RNAME=LINKSTAI 


ACF/VTAM attempts to activate the adjacent link stations 0C2-S and 
LINKSTA1. The activation of LINKSTA1 in NCP1 is delayed because NCP 1 
receives no response to link-level commands sent on the SDLC link to NCP2’s 
communication controller before and during the loading of NCP2 over the 
channel OC2. Because the channel adapter is enabled, the activation of 0C2-S 
proceeds and ACF/VTAM begins the loading of NCP2 over the channel. After 
the load completes and LINKSTA2 is activated, contact is established with 
NCP1, and the activation of LINKSTA1 completes. 


The fact that there is no resource hierarchy among major nodes means that any 
NCP major node can be deactivated at any time. The deactivation of an NCP 
does not cause ACF/VTAM to deactivate any other NCP. However, due to 
the topological relationship among subarea nodes, deactivation of an NCP or a 
cross-subarea link or link station can have significant and disruptive effects on 
other subarea nodes. 


To avoid disrupting sessions, the operator must be concerned about the status of 
cross-subarea links and link stations after an NCP deactivation. There are two 
types of cross-subarea links to be concerned with: same-domain links and 
cross-domain links. Those links connecting two subarea nodes that are both 
active in the operator’s domain are same-domain links; those links connecting a 
subarea node that is active in the operator’s domain with a subarea node that is 
not active in the operator’s domain are cross-domain links. 


Same-domain links are governed by the following rule. When the operator 
enters a VARY INACT command for an NCP, ACF/VTAM automatically 
deactivates any link or link station in an adjacent subarea node that was 
automatically activated when the NCP was activated. ACF/VTAM does not 
perform these automatic deactivations if the links and link stations were also 
directly or indirectly activated by the operator. (ACF/VTAM never deactivates 
same-domain links and link stations from the side within an NCP being 
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deactivated. Deactivation from the other side, if it is done, is sufficient to take 
down the link.) 


The rule for cross-domain links is as follows. When the operator enters a 
VARY INACT command for an NCP, ACF/VTAM indirectly deactivates any 
cross-domain link or link station unless CDLINK=ACT is specified on the 
VARY INACT command. 


(The CDLINK operand also applies to the HALT command. See “Halting 
ACE/VTAM” for a discussion of how cross-subarea links are treated when 
ACF/VTAM is halted.) 


Figure 2-3 can be used to illustrate these rules. NCP1 and NCP2 have been 
activated by HOST1 (and thus are in HOST1’s domain). NCP3 has not been 
activated by HOST (and is therefore not in HOST1’s domain). Therefore, the 
link between NCP1 and NCP2 is a same-domain link, and the link betwcen 
NCP2 and NCP3 is a cross-domain link. HOST1 is to deactivate NCP2. 


The same-domain link between NCP1 and NCP2 was made available through 
the activation of LINK1 and LINKSTA1 by HOST1. This link and link station 
could have been: 


Directly or indirectly activated (for example, the operator could have 
entered specific VARY ACT commands for LINK1 and LINKSTAI, or 
LINK1 and LINKSTAI1 could have been defined to be initially active in 
NCP1?’s definition statements) 


Automatically activated when NCP2 was activated (by specifying 
LINKSTA1 in the RNAME operand of the VARY ACT command or the 
NCP definition for NCP2) 


If LINK1 and LINKSTAI were automatically activated, then when NCP2 is 


deactivated, LINK1 and LINKSTAI1 are automatically deactivated, unless they 
were also directly or indirectly activated. 
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LINKSTA4 


Therefore, if the link between NCP1 and NCP2 is to continue to carry session 
traffic after NCP2 is deactivated by HOST1, the operator should ensure that 
LINK1 and LINKSTA1 were directly or indirectly activated. This can be 
verified by entering a DISPLAY command for the link or link station (a 
DISPLAY of either resource displays the status of both). 


(Note that in this example the activation of LINK2 and LINKSTA2 by HOST! 
has no effect on the availability of the link between NCP1 and NCP2. The 
activation of LINK2 and LINKSTA2 that is required to make the link itself 
available must have occurred by specifying SDLC monitor mode for LINK2 in 
NCP2’s definition, or by HOST2’s activating NCP2, LINK2, and LINKSTA2. 
If LINK2 and LINKSTA2 are activated by HOST1, HOST1’s ACF/VTAM 
does not deactivate them when NCP2 is deactivated. In this case, ACF/VIFAM 
loses its ownership of LINK2 and LINKSTA2 within NCP2 by virtue of the 
deactivation command sent to NCP2 itself.) 


The cross-domain link between NCP2 and NCP3 was made available through 
the activation of LINK3 and LINKSTA3 by HOST1. Because this link is a 
cross-domain link, by definition, NCP3 was not activated by HOST1, and 
LINK3 and LINKSTA3 could not have been automatically activated. 
Therefore, a cross-domain link and link station must be directly or indirectly 
activated. When NCP2 is deactivated, ACF/VTAM indirectly deactivates all 
cross-domain links and link stations (because they are below the NCP in the 
resource hierarchy), unless CDLINK=ACT is specified in the VARY INACT 
command . 


Therefore, if the link between NCP2 and NCP3 is to continue to carry session 
traffic after NCP2 is deactivated by HOST1, the operator should specify 
CDLINK=ACT on the VARY INACT command for NCP2. 


(As in the parenthetical explanation of the activation of LINK2 and LINKSTA2 
above, LINK4 and LINKSTA4 must have become active in NCP3 either 
through the SDLC monitor mode function or through activation by HOST2.) 


The order of deactivation of NCPs determines the way in which an 
ACF/VTAM domain contracts. (As explained above, the deactivation of an 
NCP by an ACF/VTAM host removes that NCP from the domain of that 
host.) After an NCP is deactivated in a domain, all links leading to it are 
considered cross-domain links. During an NCP deactivation, then, same-domain 
links might become cross-domain links. If two or more NCPs are deactivated 
simultaneously (except as a result of a HALT command, see “Halting 
ACF/VTAM”), the time when the change occurs is unpredictable, and it might 
be difficult to apply the previously described rules for not disrupting sessions. 
Unless these rules are followed such that all links have the same final 
disposition (active or inactive), regardless of which rule applies, NCPs should not 
be deactivated simultaneously. 


Because the topological shape of a domain changes when an NCP is 
deactivated, the operator should be aware of the possibility of creating a 
discontiguous domain. In Figure 2-3 for example, if HOST1 had activated 
NCP3 as well as NCP1 and NCP2, and if HOST1 then deactivated NCP2, 
NCP3 would be in an isolated part of HOST1’s domain. That is, HOST1, 
NCP1, and NCP3 would all be part of the domain, but the only access to NCP3 
from HOST1 is through NCP2, which would not be in the domain. (Continued 
session traffic might or might not be possible to resources in or beyond NCP3, 
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depending on whether the deactivation of NCP2 caused deactivation of the 
cross-subarea links connected to NCP2, as previously described.) 


Discontiguous domains should be avoided because, in this example, the lack of 
ownership by HOST1 of elements of the route to NCP3 means that the HOST1 
operator will not get notification of failures of links and link stations in NCP2. 
(The operator will always get notification of explicit route failures.) In addition, 
ACF/VTAM’s ability to recover link station failures in NCP2 is lost. Finally, if 
NCP3 fails, the HOST1 operator will have no capability for reloading that 
communication controller. 


To avoid a discontiguous domain, always deactivate those NCPs first that are 
farthest away from the host, working inward toward the host. In this example, 
HOST1 should deactivate NCP3 first, NCP2 second, and NCP1 last. NCPs 
need not be deactivated before halting ACF/VTAM to ensure that the proper 
order of deactivation is followed. ACF/VTAM follows special procedures 
during its halt processing to simultaneously deactivate all NCPs that are still 
active in the domain (see “Halting ACF/VTAM”). 


If a discontiguous domain exists, a// cross-subarea links connected to an isolated 
NCP are cross-domain links. When the NCP is eventually deactivated, the only 
way to ensure an orderly deactivation is to specify CDLINK=ACT on the 
VARY INACT or HALT command. 


Dynamic Reconfiguration of an NCP 


If the physical configuration of the physical units and logical units in an NCP 
major node is changed (for example, a peripheral physical unit is moved from 
one line to another), one or more VARY DRDS commands can be used to 
inform the NCP of the changes without having to generate a new NCP. To use 
the VARY DRDS command, the system programmer must define the 

appropriate dynamic reconfiguration (DR) files, as described in the ACF/VTAM 
Planning and Installation Reference manual. 


An NCP to be reconfigured must be active. Any logical units in the existing 
configuration that are to be deleted by the reconfiguration must be inactive. 
The physical units to which these logical unit are subordinate must also be 
inactive. 


Dynamic reconfiguration is not meant to replace NCP generations, but to 
supplement them to allow quick and efficient control of changes in the domain 
configuration. Dynamic reconfiguration should be used as a temporary method 
of reconfiguration; a new NCP should be generated to reflect the changes as 
soon as time permits. 


Changing NCP Line Scheduling Parameters 
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ACF/VTAM allows the operator to change the line scheduling parameters in 
the NCP for a line attaching polled nonswitched BSC 3270 devices. These 
values can be set as often as desired while the NCP is active. When the NCP is 
deactivated and later reactivated, the parameter values in effect are the ones in 
the NCP definition, unless a configuration restart file was defined for the NCP. 
In that case, the line scheduling parameters are restored to their checkpointed 
values, regardless of whether the WARM option is used when the NCP is 
reactivated. | 


Switched Devices 


The MODIFY NEGPOLL command is used to change the negative polling limit. 
The negative polling limit is the maximum number of consecutive negative 
polling responses the NCP accepts from a terminal on a line before it starts 
polling another terminal on the line. 


The MODIFY POLL command is used to change the polling delay. If an NCP 
is polling a line, the polling delay is the number of seconds the NCP waits 
before polling the line again. 


The MODIFY SESSION command is used to change the line scheduling session 
limit. The line scheduling session limit is the maximum number of NCP line 
scheduling sessions allowed at the same time on a polled line. Normally the 
limit should be no greater than the maximum number of terminals on the linc. 
A changed limit does not become effective until the current number of sessions 
falls below the new limit. 


Switched lines and placeholder physical units are defined in an NCP major 
node. The actual physical units, their switched paths (that is, telephone 
numbers), and their subordinate logical units are defined to ACF/VTAM in 
switched major nodes. For switched lines using the X.21 Direct Call capability, 
ACF/VTAM does not need to know the telephone numbers. Instead the 
switched physical unit definition specifies the switched line to be used, and the 
X.21 network establishes the connection automatically when requested. 


The VARY ACT command is used to activate the physical units and logical 
units in a switched major node, just as it is for physical units and logical units in 
other major nodes. For physical units in a switched major node, activation docs 
not establish a physical connection; activation just asks ACI'/VTAM to accept 
incoming calls from the physical unit or to initiate outgoing calls on behalf of 
application programs. ACF/VTAM waits for a physical unit to call in or for an 
application program to request a session before trying to establish a physical 
connection. 


The VARY INACT command is used to deactivate the resources in a switched 
major node. Deactivation of switched resources means that switched 
connections involving those resources can no longer be created, and therefore 
no new sessions can be established. 


Note: A forced deactivation of a switched physical unit does not actualiy 
deactivate the physical unit. Forced deactivation does the equivalent of a VARY 
INACT,R command. That is, all existing switched connections are broken, and 
the switched physical unit is left eligible to establish new switched connections. 
A normal or immediate deactivation must be used to deactivate a switched 
physical unit. 


A session involving a switched logical unit can be initiated by either session 
partner. A terminal operator or an ACF/VTAM application program can 
request a session. Terminal opcrators use dial-in lines and ACF/VTAM 
application programs use dial-out lines. 


For purposes of the following discussion, normal dial-in refers to calls 
originating from a physical unit, automatic dial-out refers to a call established 
by ACF/VTAM using the communication controller’s autocall unit, and manual 
dial-out refers to an ACF/VTAM-operator-assisted call from the 
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- communication controller to the physical unit. 


_ For normal dial-in operation, the terminal operator calls the communication 


controller, and the NCP notifies ACF/VTAM of the incoming call. 
ACF/VTAM then requests that the physical unit identify itself. When the 
physical unit responds, ACF/VTAM locates the proper physical unit definition 
in an active switched major node. After ACF/VTAM completes activation of 
the physical unit and its subordinate logical units, sessions involving the logical 
units can be initiated as if the line were nonswitched. 


When an application program requests a session, ACF/VTAM selects a dial-out 
line. Depending on the capabilities of the switched line, the dial-out can be 
automatic (done entirely by ACF/VTAM and the NCP) or manual (done partly 
by the ACF/VTAM operator). 


For automatic dial-out, ACF/VTAM sends the telephone number or an X.21 
Direct Call request to the NCP. The NCP establishes the connection to the 
physical unit, using either its communication controller’s autocall unit or the 
Direct Call facility of an X.21 network. The NCP notifies ACF/VTAM when 
the connection is complete. ACF/VTAM then verifies the identity of the 
physical unit. From this point, the process continues as for a dial-in connection. 


For manual dial-out, ACF/VTAM displays a message with the line and 
telephone number to use. The ACF/VTAM operator manually calls the 
physical unit. The NCP notifies ACF/VTAM when the switched connection is 
complete, and ACF/VTAM then verifies the identity of the physical unit. 
From this point, the process continues as for a dial-in connection. 


If the ACF/VTAM operator is unable to complete a manual dial-out, the 
VARY INOP command can be used to specify whether ACF/VTAM is to 
select an alternate line or terminate the dial-out operation. 


Dial-out requests (except for X.21 Direct Call) can be placed on one of a 
number of switched paths to a physical unit as defined within a switched major 
node. The dial-out path assignment for switched physical units can be 
controlled by making switched paths usable or not usable with the VARY 
PATH command. This command can be used for individual switched paths by 
specifying the path identifier (PID), or for a group of switched paths by 
specifying the group identifier (GID). For example, all switched paths that use 
Wide Area Telephone Service (WATS) lines for dial-out connections can be 
associated with a GID in the switched major node definition, and can be made 
usable or not usable as a unit. 


Switched lines with dial-in capability can allow or disallow incoming calls. For 
an incoming call to be allowed, the line must be in answer mode. The mode 
setting can be specified in the definition statement for the line and can be 
changed with the ANS operand of the VARY ACT command when activating 


. the line, or with the VARY ANS command after the line is active. 
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A cross-domain resource manager (CDRM) is that part of an SSCP that 
supports cross-domain session setup and takedown. The CDRM defined to 
represent the SSCP in the operator’s domain is called the host CDRM. The 
CDRMs defined to represent the SSCPs in other domains are called external 


CDRMs. Before logical units in one domain can have cross-domain sessions 
with logical units in another domain, an SSCP-to-SSCP session must be 
established between the SSCPs of the two domains. First, the host CDORM 
major node and the host CDRM must be activated in each domain. This 
enables each host CDRM to request sessions with and to accept session requests 
from other known CDRMs (SSCPs). Next, the external CDRMs must be made 
known to each ACF/VTAM by activating the CDRM major nodes containing 
these CDRMs. Finally, an SSCP-to-SSCP session is established between two 
domains when one or both of the operators in the two domains activates the 
external CDRM representing the other domain. This activation of an external 
CDRM causes ACF/VTAM to request a session with the SSCP that the 
external CDRM represents. The request is rejected unless the other domain has 
activated both its host CDRM and the CDRM major node that contains the 
external CDRM representing the SSCP making the request. 


The effects of a CDRM deactivation on LU-to-LU sessions are the same as for 
other resource deactivations, as described under “Deactivating Resources.” he 
sessions affected are: 


For deactivation of an external CDRM, all LU-to-LU sessions with logical 
units controlled by the SSCP represented by the external CDRM. 


For deactivation of the host CDRM, all LU-to-LU sessions with logical 
units controlled by any SSCP in another domain. 


The loss of an SSCP-to-SSCP session (for example, as the result of a link 
failure) is not the same as external CDRM deactivation and does not terminate 
existing LU-to-LU sessions. However, new sessions with logical units 
controlled by the SSCP that was lost cannot be started until the SSCP-to-SSCP 
session is reestablished. See ““SSCP-to-SSCP Session Failure” in Chapter 3 for 
information (including migration considerations) on SSCP session recovery. 


When defining the host CDRM, the system programmer can specify whether the 
host CDRM is authorized to dynamically define cross-domain resources. The 
system programmer can also specify which external CDRMs, if any, are 
authorized to make use of this dynamic definition capability. If the host CDRM 
and an external CDRM are so authorized in an ACF/VTAM domain, the 
other-domain SSCP represented by the external CDRM can request a session 
setup on behalf of a logical unit for which no cross-domain resource (CDRSC) 
was defined in the domain receiving the request (that is, the domain containing 
the authorized host and external CDRM definitions). The receiving SSCP 
handles the request by dynamically creating a temporary CDRSC definition for 
the logical unit. 


A DISPLAY ID=cdrm-name command can be used to determine whether a 
CDRM is the host CDRM or an external CDRM. For the host CDRM, the 
display indicates whether dynamic CDRSC definition was authorized. For an 
external CDRM, the display indicates whether pre-definition of CDRSCs 
controlled by the represented other-domain SSCP is required. The output of a 
DISPLAY command with the EVERY or ACT option for an external CDRM 
includes both pre-defined and dynamically-defined CDRSCs controlled by the 
other-domain SSCP represented by the external CDRM. 
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Cross-Domain Resources 


Dynamically-Defined CDRSCs 


A cross-domain resource (CDRSC) is a representation in one domain of a 
logical unit (either application program or device-type logical unit) controlled by 
an SSCP in another domain. CDRSCs can either be pre-defined (in a CDRSC 
major node set up by the system programmer) or dynamically-defined (in the 
CDRSC major node ISTCDRDY set up by ACF/VTAM). 


The operator can make cross-domain resources available to the domain by 
activating and deactivating CDRSC major and minor nodes. For 
communication to take place between logical units in different domains, the 
SSCPs must be in session as described under “Cross-Domain Resource 
Managers,” and the session partners (logical unit and CDRSC in each domain) 
must be active. (Note that a CDRSC definition is not required in the domain 
of a logical unit receiving a cross-domain session request if the dynamic CDRSC 
definition function is being used.) 


As introduced above and in the section “Cross-Domain Resource Managers,”’ 
ACF/VTAM can dynamically define certain CDORSCs. With the proper 
authorization in the CDRM definitions, ACF/VTAM dynamically defines a 
CDRSC when a cross-domain session setup request is received from another 
SSCP for an unrecognized resource name. For a discussion of environments 
that might benefit from the use of dynamically-defined CDRSCs, see the 
ACF/VTAM Planning and Installation Reference manual. 


Dynamically-defined CDRSCs are collected in a CDRSC major node named 
ISTCDRDY. ISTCDRDY is activated automatically by ACF/VTAM when tlie 
host CDRM is activated, if dynamic definition support has been specified in the 
host CDRM definition. ISTCDRDY is likewise deactivated automatically by 
ACF/VTAM when the host CDRM is deactivated. 


The dynamic CDRSC definition function is active whenever all of the following 
conditions are met: 


e The system programmer has defined the host CDRM to allow dynamic 
definition of CDRSCs. 


e The host CDRM is active. 
e ISTCDRDY is active. 


Note that even with the dynamic CDRSC definition function fully active (with 
all of the above conditions met), an external CDRM definition must specify the 
function and the external CDRM must be active before a session can be 
established with a dynamically-defined cross-domain resource controlled by the 
external CDRM. 


In general, the ACF/VTAM operator has the same control of 
dynamically-defined cross-domain resources as for pre-defined CDRSCs. Of 
course, no VARY ACT command is available or necessary, because a 
dynamically-defined CDRSC is considered active when it becomes dynamically 
defined. Phe DISPLAY ID and VARY INACT commands can both be used for 
dynamically-defined CDRSCs. 


Likewise, the operator generally has the same control of the CDRSC major 
node ISTCDRDY as for other CDRSC major nodes. The DISPLAY ID, 
MODIFY CDRM, VARY ACT, and VARY INACT commands can all be used 
for the CDRSC major node ISTCDRDY. 


While the host CDRM is active, the operator can deactivate ISTCDRDY with 
the VARY INACT command, in which case all dynamically-defined CDRSCs 
are also deactivated and the dynamic CDRSC definition function is disabled. 
The dynamic CDRSC definition function remains disabled until ISTCDRDY is 
activated again. ISTCDRDY can be activated again by a VARY ACT 
command naming ISTCDRDY directly, or by activating the host CDRM (even 
if the host CDRM is already active). If the host CDRM is inactive or if the 
host CDRM is not defined to allow the dynamic CDRSC definition function, 
activating ISTCDRDY does not provide the function. 


Dynamically-defined CDRSCs are deactivated and deleted by ACF/VTAM on 
a periodic basis if they are not in use. That is, if a CDRSC has no active 
sessions and has had none for a defined interval of time, the CDRSC definition 
is discarded. Note that a dynamically-defined CDRSC that becomes a shadow 
resource (see ““Shadow Resources” in Chapter 3) has all of its sessions moved 
to the corresponding logical unit definition, and thus is considered to have no 
active sessions aS soon as it becomes a shadow resource. See the ACKF/VTAM 
Planning and Installation Reference manual for information about the time 
interval for dynamically-defined CDRSC deletion. 


Changing CDRMs for Cross-Domain Resources 


An external CDRM is named in the definition of each CDRSC to indicate the 
other-domain SSCP that controls the logical unit represented by the CDRSC 
definition. Such an external CDRM is referred to as the “owning CDRM” of 
the CDRSC. The ownership of a CDRSC can be changed if an SSCP in 
another domain loses its SSCP-to-LU session with the logical unit represented 
by the CDRSC, and another SSCP (still in another domain) takes over the 
logical unit. (See “Error Recovery Procedures for Failures in a 
Multiple~Domain Network” in Chapter 3 for a discussion of resource takeover.) 
The MODIFY CDRM command is used to inform ACI /VIfAM of the 
takeover, naming the two external CDRMs involved (the previous owner of the 
CDRSC and the new owner). This command can be used whether the CDRSC 
is active or inactive. If the CDRSC is already in session with a logical unit in 
the operator’s domain, the session is undisturbed, but any new session setups 
are handied through the SSCP represented by the new owning CDRM. 


The MODIFY CDRM command does not need to be used for 
dynamically-defined CDRSCs. If a session setup request is reccived for a 
dynamically-defined CDRSC from a CDRM other than the current CDRM 
owner, ACF/VTAM automatically changes the CDRM ownership of the 
CDRSC. However, the operator might still want to use the MODIFY CDRM 
command if LU-to-LU session recovery is initiated by the logical unit that 
received the original session request. For example, suppose a terminal user 
originally logged on to an application program, with the CDRSC representing 
the terminal being defined dynamically in the domain of the application 
program. If the session between the application program and the terminal is 
disrupted, the application program might try to reinitiate the session instead of 
requiring the terminal user to logon again. In this case, the ACI /VTAM 
operator in the domain of the application program needs to use the MODIVY 
CDRM command to change the CDRM owner of the CDRSC representing the 
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terminal, if the terminal is taken over by a backup SSCP other than the SSCP in 
the application program’s domain. 


Note that an ACF/VTAM domain that takes over a cross-domain resource does 
not need to use the MODIFY CDRM command, because in this case 
ACF/VTAM’s shadow resource function applies. See “Shadow Resources” in 
Chapter 3 for more information. 


Monitoring the Domain 


ACF/VTAM automatically provides the operator with messages that contain 
information about the ACF/VTAM domain. If more information is required, 
various DISPLAY commands are available to request status information about 
domain resources, and to verify changes resulting from previous operator 
requests. In general, DISPLAY commands can be used to obtain status 
information about active major nodes and their minor nodes (active or inactive). 
Some DISPLAY commands can be used to obtain information about resources 
that are not nodes. For example, the DISPLAY BFRUSE command provides 
information about ACF/VTAM’s use of buffers. 


The DISPLAY ID command is used to request the status of a particular 


resource. The name of the resource is provided as the value of the ID operand. 


DISPLAY commands can be used to obtain information about: 
e The explicit routes and virtual routes known to ACF/VTAM (DISPLAY 
ROUTE or DISPLAY PATHTAB) 


¢« Any major node (other than an application program major node) or all 
active major nodes (DISPLAY ID=major node name or DISPLAY 
MAJNODES) 


¢ Any or all application programs (DISPLAY ID=application program name 
or DISPLAY APPLS) 


e Any or all lines (DISPLAY ID=line name or DISPLAY LINES) 


e Any or all link stations (DISPLAY [ID=link station name or DISPLAY 
STATIONS) 


- Any or all physical units (DISPLAY ID=physical unit name or DISPLAY 
CLSTRS) 


fe 6 Any or all device-type logical units (DISPLAY ID=logical unit name or 
DISPLAY TERMS) 


e Djial-out path information for a physical unit in a switched major node 
(DISPLAY PATHS) 


¢ In OS/VS2 (MVS), any TSO user ID (DISPLAY U) 


e Any node with session-activation or termination I/O pending (DISPLAY 
PENDING) | 


e Any or all cross-domain resource managers (CDRMs) (DISPLAY ID=cdrm 
name or DISPLAY CDRMS) 


¢ Any or all cross-domain resources (CDRSCs) (DISPLAY ID=cdrsc name or 
DISPLAY CDRSCS) 
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« The virtual route (VR) and transmission priority (TP) numbers for an 
LU-to-LU session. (DISPLAY [D=application Program or logical unit or 
cdrsc name. Note that for some cross-domain sessions, such as for those 
involving logical units attached to an NCP, this information is not available 
to ACF/VTAM and is not displayed.) 


For a summary of some of the information available from these DISPILAY 
commands, see the descriptions of them in Chapter 4. See Appendix A for 
examples of display output. For an explanation of the messages that make up 
the display output, see ACF/VTAM Messages and Codes. 


When entering DISPLAY commands, the operator should try to use the most 
limited command that will get the required information. ‘These commands 
require sizeable storage allocations and affect storage requests from other parts 
of ACF/VTAM. For example, if the required information can be obtained 
from a DISPLAY ID=logical unit name command, that command should be 
used rather than a DISPLAY ID=its major node name command. Sometimes a 
limited request for a display is not possible. In this case, the ACF/VTAM 
operator could try requesting the display when there is not much activity in the 
domain. If the need for the display information is immediate, a judgement can 
be made as to whether the display is more important than its possible adverse 
effects on ACF/VTAM operation. 


Terminating Sessions with Operator Commands 


The usual way for a session to be terminated is for one of the session partners 
to request termination. However, the operator can also terminate sessions by 
using the VARY TERM or VARY INACT command. 


The VARY TERM command allows the operator to terminate a particular 
session or set of sessions without deactivating either of the session partners. 
Added control of session termination is provided by the SCOPE and TYPE 
operands on the VARY TERM command. 


Another way of terminating a session is to use the VARY INACT command for 
one of the logical units participating in the session. This command with one of 
the I, F, or R operands breaks any sessions with the logical unit. See “Resource 
Deactivation” earlier in this chapter for more information on the effect that 
resource deactivation has on sessions. 


Halting ACF/VTAM 


ACF/VTAM can be halted as a result of the HALT or HALT QUICK 
commands. When ACF/VTAM is halted, all of its resources are deactivated 
and all sessions involving those resources are terminated. If the HALT or 
HALT QUICK commands do not properly complete, the operator can. cancel 
ACF/VTAM. These methods of halting ACF/VTAM are described below. 


The CDLINK operand for the HALT command is the same as for the VARY 
INACT command, except that the cross-subarea links to which it applies are 
determined when the HALT command is entered and are not redefined as the 
domain contracts. That is, the CDLINK operand applies to all cross-subarea 
links that are cross-domain at the time the HALT command is entered. 
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Except for channel links, all other cross-subarea links (those that are entirely 
within the domain at the time the HALT command is entered) remain active 
during and after the halt, regardless of how CDLINK is specified. That is, their 
final status does not depend on whether the links and their link stations were 
automatically, directly, or indirectly activated. This allows non-disruptive, 
simultaneous NCP deactivations, regardless of how the communication 
controllers are connected within the domain. Cross-subarea channel links are 
always deactivated during an ACF/VTAM halt. 


HALT and HALT QUICK Commands 


Canceling ACF/VTAM 


42 


For a normal halt, enter the HALT command. The HALT command notifies 
application programs of the domain shutdown and waits for them to close their 
ACBs. New sessions are not permitted and new ACBs may not be opened, but 
otherwise the application programs can continue their current operations. After 
all application programs have stopped using ACF/VTAM services (that is, after 
they have closed their ACBs), processing is the same as for the HALT QUICK 
command, described below. 


During a normal halt, the ACF/VTAM operator can monitor the shutdown of 
the domain by displaying the status of application programs and other logical 
units. The VARY TERM command can be used to terminate sessions, if 
necessary, to speed the processing of the HALT command. 


The HALT QUICK command can also be used at this time, if necessary, to 
speed halt processing. The HALT QUICK command notifies application 
programs of the domain shutdown and then proceeds with the equivalent of 
VARY INACT,I commands for each major node. After ACF/VTAM has 
received a HALT QUICK command, the only ACF/VTAM commands that can 
be used are DISPLAY commands, VARY TERM commands (to terminate 
sessions), and VARY INACT,F commands (to force the deactivation of 
resources). In VSE systems, MODIFY DETACH commands can also be used 
to detach ACF /VTAM subtasks. In OS/VS systems, the HALT CANCEL 
command can be used to cancel ACF/VTAM. 


If, during HALT QUICK processing, after all the major nodes are inactive, any 
application programs have not yet closed their ACBs, ACF/VTAM displays a 
message listing the names of these application programs. Because ACF/VTAM 
cannot shut down the domain until all application programs have been 
disconnected from ACF/VTAM, the operator might want to speed up the halt 
process by canceling the jobs of application programs with open ACBs. The 
HALT QUICK command can prevent an application program from using 


ACF/VTAM services, but ACF/VTAM cannot force the program to disconnect 


itself from ACF/VTAM. When the operator cancels an application programm, 
the host operating system disconnects it from ACF/VTAM. 


It might be necessary to cancel ACF/VTAM if ACF/VTAM cannot be halted 
in any other way. ACF/VTAM should be canceled only if the HALT and 
HALT QUICK commands do not work properly. Canceling ACF/VTAM 
causes the immediate abnormal termination of ACF/VTAM without an orderly 
shutdown of the domain. The method used to cancel ACF/VTAM differs in 
VSE and OS/VS systems. | 


In VSE systems, ACF/VTAM is canceled by canceling ACF/VTAM’s partition. 


In OS/VS systems, ACF/VTAM is canceled by using the HALT CANCEL 
command. This command depends only on the proper functioning of the host 
operating system’s abnormal termination facilities. The HALT CANCEL : 
command causes an abnormal termination with the system completion code hex | 
OA9. No further I/O operations are performed. Application programs using ~ 
ACE/VTAM are notified of an ACF/VTAM shutdown through their TPEND 
exit routines, if possible. Data in the process of being transmitted on sessions 
might be lost. If TPEND cannot be scheduled for an application program, the | 
application program is also abnormally terminated, if possible. In extraordinary | 
circumstances, the operator might have to cancel some application programs. 


Using Diagnostic Facilities 


This section gives a brief summary of the diagnosic facilities that are available 
through ACF/VTAM operator commands. For a more detailed description of 
when and how to use these facilities, see ACF/VTAM Diagnosis Guide. 


Displaying and Testing Routes 


The DISPLAY ROUTE command is used to provide information about what 
routes are available between the ACF/VTAM host node and a destination 
subarea node. In addition, the TEST operand of the DISPLAY ROUTE: 
command allows the operator to test the explicit routes between the host node 
and a destination subarea node for the routes’ ability to transfer data between 
the subareas. The routes to be displayed can be specified by explicit route 
number, virtual route number, or class of service name. If the TEST operand is 
specified and the routes to be displayed are specified by virtual route number, 
the explicit routes tested are those to which the specificd virtual routes arc 
currently mapped. If the TEST operand is specitied and the routes to be 
displayed are specified by class of service name, the explicit routes tested are 
those to which the virtual routes in the specified class of service are currently 
mapped. See “Route Verification” in Chapter 3 for more information. 


The DISPLAY PATHTAB command also provides information abcut routes, 
but without the capability to test routes. The information available is a subset 
of that provided by the DISPLAY ROUTE command, but in a different format. 
The DISPLAY PATHTAB command was available in previous releases of 
ACE/VJTAM. The DISPLAY ROUTE command can be considered to be a 
replacement for it. 


Dumping an NCP 


An NCP can be dumped by either of two methods: a static dump or a dynamic 
dump . 


A static dump is requested by entcring the MODIFY DUMP command without 
the DYNA operand, or by replying in the affirmative when ACE'/VVAM offers 
to dump a failed NCP (message ISTO95A in OS/VS or message 5A95A in 
VSE). The latter method occurs during error recovery procedures for an NCP 
and is more thoroughly described in Chapter 3 under “Dumping and I.cading an 
NCP.” When a static dump is requested, NCP processing stops and the current 
storage contents of the NCP are dumped. This dump effectively destroys a 
running NCP. The NCP must be reactivated (and rcloaded) before 
communication with that NCP can resume. 
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Selecting a Dump Station 
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A static dump can also be obtained by using the NCP independent dump utility, 
if the NCP is in a channel-attached communication controller. For more 


_ information, see the ACF/NCP/VS Utilities manual. 


A dynamic dump is requested by entering the MODIFY DUMP command with 
the DYNA operand. When a dynamic dump is requested, NCP processing 
continues while the NCP’s contents are being dumped. A dynamic dump thus 
reflects the storage contents of the communication controller over a period of 
time. 


To print the contents of the NCP dump file, use the NCP independent dump 
utility described in the ACF/NCP/VS Utilities manual. 


In OS/VS only: If an expiration date exists for the dump data set and it has 
not yet been reached, do not respond to message [EC107D (in OS/VS1) or 
IEC507D (in MVS) by entering REPLY xx,’M’. Enter REPLY xx,’U’ to 
override the expiration date and allow write access to the data set, or see the 
system programmer if write access cannot be allowed for this data set. Entering 
REPLY xx,’M’ causes ACEF/ VTAM to be abnormally terminated by the 
operating system. 


When dumping an NCP, ACF/VTAM needs to know the name of the adjacent 
link station through which the dump operation is to be carried out. The dump 
station can be either a channel link station or an SDLC link station. 
ACF/VTAM can be allowed to select a dump station, or the system 
programmer or the operator can specify a dump station. The dump station can 
be specified in the NCP definition, on the VARY ACT command, on the 
MODIFY DUMP command, or during NCP error recovery if ACF/VTAM asks 
the operator whether the NCP should be dumped. ACF/VTAM selects the 
dump station whenever there is no dump station name currently in effect from 
one of the above sources. 


When ACF/VTAM selects a dump station, it selects a channel link station, if 
one is available. If no channel link station is available, ACF/VTAM uses any 
available SDLC link station. 


If the operator wants to override a dump station name specified in an NCP 
definition, the DUMPSTA operand of the VARY ACT command can be used 
to specify the name of another link station. This override capability can also be 
used to specify that ACF/VTAM should select the dump station, despite the 
NCP definition. This is done by specifying a null value for the dump station 
(that is, specifying DUMPSTA without a value). If the operator chooses not to 
override the NCP definition value, ACF/ VITAM uses that definition value to 
determine the link station to be used. The DUMPSTA operand of the © 
MODIFY DUMP command can likewise be used to override a dump station 
name specified in an NCP definition or on the VARY ACT command. 


A link station chosen as a dump station must also be specified for automatic 
activation with the NCP, or must be already active when it is needed (with 
ACF/VTAM thus knowing of its connection to the NCP). The former method 
is recommended. If a specified dump station is not available for a dump 
operation resulting from a MODIFY DUMP command, the command fails. If a 


‘specified dump station is not available for a dump operation resulting from error 


recovery procedures for an NCP, ACF/VTAM either prompts the operator for 


Link Level 2 Test 


a link station name or selects a link station from among those that are availabic. 
as described above. (See “Dumping and Loading an NCP” in Chapter 3 for 
details regarding NCP error recovery procedures. ) 


As with the link stations specified for automatic activation with an NCP, the 
reconnection of cross-subarea links from one communication controller to 
another might require the changing of dump station specifications for those 
NCPs intended to run in the communication controllers. The WARM start 
option and the WARM operand of the VARY ACT command should be 
avoided when activating the affected NCPs if the dump station specifications 
are changed. 


Note that any link to be used to dump (or load) a communication controller 
must be defined to both the NCP and the communication controller as being 
capable of initial program load (IPL). For the NCP this is done by specifying 
[PL=YES on the LINE macro instruction in the NCP definition. For the 
communication controller, the ability of a link to accept an IPI. is indicated in 
the configuration data set (CDS) residing in the controller’s diskette storage. 
Any attempt to dump the communication controller over an SDLC link that is 
not so specified will fail (including an attempt resulting from the selection of an 
otherwise available SDLC link station by ACF/VTAM in the absence of a 
specific DUMPSTA specification). 


The ACF/VTAM link level 2 test is used to test an SDLC communication line 
between an NCP and one of its.peripheral physical units, or between two NCPs. 


The operator can specify: 


« Either a continuous link test or the number of test transmissions to be sent 
e The cancelation of an ongoing link test 


e Any user data to be included in the test transmissions 


The test data is returned from the remote station (NCP or peripheral PU) to the 
controlling NCP. This NCP then compares the data received. with the data sent 
and forwards the results to ACF/VTAM. The following information is 
displayed by ACF/VTAM: 


e The number of test messages sent 
« The total number of test messages returned (including those in error) 


« The number of test messages returned without error 


For a link level 2 test between an NCP and a peripheral physical unit, the 
SDLC link must be active and the physical unit must be inactive before the link 
level 2 test is started. The name of the physical unit must be specified on the 
ID operand of the MODIFY LL2 command. This test can be done on a 
point-to-point line, or on a multipoint line without affecting any other physical 
units on the line. 


For a link level 2 test between two NCPs, the SDLC link to be tested must be 


active and the associated link stations must be inactive in each of the two NCPs 
prior to requesting the link level 2 test. In a multiple-domain network with 
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Intensive Mode Recording 


shared host ownership of link stations, both link stations must be inactive to all 
SSCPs. The name of the link station in the NCP initiating the test must be 
specified on the ID operand of the MODIFY LL2 command. 


Migration Considerations: For ACF/NCP/VS Release 2, an NCP definition 
must specify whether the NCP is the primary or secondary end of an SDLC 
link. The link level 2 test can be initiated only from the NCP at the primary 
end of the link. 


Because ACF/NCP/VS Release 2 does not support multiple-link transmission 
groups, the system programmer might define a backup link to be used if the 
principal link fails. (See the migration considerations under “Error Recovery 
Procedures for Link Failures” in Chapter 3.) If an ACF/NCP/VS Release 2 is 
initiating the link level 2 test, the link that is tested could either be the principal 
link (the link being backed up) or the backup link. The choice of which link 
the NCP tests is based on whether the link station associated with the principal 
link or the link station associated with the backup link was last active. If 
neither link station has yet been activated since the activation of its NCP, the 
principal link is tested. 


The operator can request detailed information concerning temporary line errors 
or other hardware error conditions by specifying the MODIFY IMR command 
to start intensive mode recording (IMR). This error information can be 
requested for a communication link between an NCP and one of its peripheral 
physical units, or between two NCP major nodes. 


For intensive mode recording on a link between an NCP and a peripheral 
physical unit, the SDLC link to be tested must be active. The name of the 
physical unit must be specified on the ID operand of the MODIFY IMR 
command. This test can be done on a point-to-point line, or on a multipoint 
line without running intensive mode recording for any other physical units on 
the line. 


For intensive mode recording on a link between two NCPs, the SDLC link to 
be tested must be active. The name of the link station in the NCP initiating the 
test must be specified on the ID operand of the MODIFY IMR command. 


On the MODIFY IMR command the operator can also specify the number of 
IMR records to be generated by the NCP. After this number is reached, IMR 
is automatically terminated for this physical unit or link station. IMR can also 
be canceled by operator command before this limit is reached. 


ACF/VTAM converts each IMR record to a miscellaneous data recorder 
(MDR) record. MDR records are written to the SYSI.LOGREC data set in 
OS/VS systems or to the SYSREC file in VSE systems. If the IBM Network 
Problem Determination Application (NPDA) program product is installed, 
ACF/VTAM can send a copy of the IMR records to NPDA. 


Identifying the Issuing Module for Each ACF/VTAM Message — 
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When diagnosing system problems, it might be useful to know which 
ACE/VTAM module caused a particular error message to be issued. The 
operator can use the MODIFY MSGMOD command to specify whether each 
ACKF/VTAM message should contain the last five characters of the name of the 


Traces 


ACF/VTAM module that originated the message. It should be noted, however, 
that this option causes certain (longer) ACF/VTAM messages to be truncated, 
with the consequent loss of potentially significant information. 


ACF/VTAM Diagnosis Guide provides a complete description of when and how 
to use ACF/VTAM traces and of the trace records that are produced by these 
traces. Chapter 4 describes the syntax of the MODIFY TRACE and MODIFY 
NOTRACE commands, which are used to start and stop ACF/VTAM traces. 
The following paragraphs give a brief overview of the kinds of traces that can 

be started and stopped with ACF/VTAM commands. 


The MODIFY TRACE command is used to start or modify the opcration of any 
one of ACF/VTAM’s traces. (ACF/VTAM traces can also be started with the 
TRACE start option.) The TYPE operand specifies the type of trace to be 
started or modified. The types of traces that can be specified are: 


e The buffer contents trace (TYPE=BUF), which records data that passes 
through ACF/VTAM’s buffers on the way to or from a specified node. 


« The buffer usage or storage management services (SMS) trace 
(TYPE=SMS), which records information about how ACF/VTAM is using 
its buffer pools. 


e The trace of I/O events (TYPE=IO), which records the order of 1/O 
events between ACF/VTAM and a network node. The trace records show 
the request/response sequence for each PIU to and from any network node. 


e The line trace (TYPE=LINE), which provides an NCP line trace. The line 
trace records the operating parameters of a line each time a level-two 
interruption occurs on that line. 


e The transmission group trace C(VYPE=TG), which provides a PIU trace of a 
transmission group. A transmission group trace can be started by naming 
any line within the transmission group. A line is part of a transmission 
group only when both the line and its subordinate link station are active. 


All the lines in the transmission group are traced as if they were a single 
logical line. Once a transmission group trace is started, another trace of the 
same transmission group cannot be requested by naming the same or 
another line within the transmission group in another MODIFY TRACE 
command. If the line or its link station subsequently fails or is deactivated 
(that is, if the line is removed from the transmission group), the 
transmission group trace is ended, even though the transmission group 
continues to operate if there are any remaining lines in the transmission 
group. The trace can be restarted, naming another line in the transmission 
group. 


The NCP line trace and the transmission group trace are mutually exclusive 
for a particular line. Therefore, when starting a transmission group trace, 
select a line that is not being used (and is not likely to be used) for a line 
trace. 


¢ In OS/VS2 (MVS), the TSO user trace (TYPE =TSO), which provides a 


trace of the input and output requests (TGET, TPUT, TPG macro 
instructions) within the TSO user ID address space. 
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e The ACF/VTAM internal trace (TYPE=VTAM), which provides a trace of 
internal ACF/VTAM activities. The OPTIONS operand can be used to 
select one or more of the following areas to be traced: 


The application program interface (APD) 


Channel I/O for channel-attached devices (CIO) 
Locking (LOCK) 
Operator messages (MSG) 


The flow of path information units (PIU) 


Events within ACF/VTAM’s process scheduling services (PSS) 
Events within ACF/VTAM’s storage management services (SMS) 


The flow of work elements through the primitive VTAM interface (PVI) 
to and from ACF/VTAM service managers (SSCP) 


In OS/VS systems, if the MODE=EXT option is specified, the records of all 
ACF/VTAM traces can be printed by the generalized trace facility (GTF). 


In VSE systems, if the MODE=EXT option is specified, the records of all 
ACF/VTAM traces can be printed by the TPRINT utility program. The 
TPRINT utility program can be run as an ACF/VTAM subtask by using a 
MODIFY TPRINT command or as a separate job by using an EXEC 
PGM=TPRINT JCL statement. 


For more information on TPRINT, see “Recording and Printing Trace Records 
and Tuning Statistics in VSE”’ later in this chapter. 


The MODIFY NOTRACE command can be used to change trace parameters or 
to stop a trace entirely. 


Recording and Printing Trace Records in OS/VS 
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In OS/VS systems, ACF/VTAM uses the generalized trace facility (GTF) to 
record ACF/VTAM trace records. The trace records are recorded in 
SYS1.TRACE along with all other GTF output. 


Three GTF options are required to record ACF/VTAM traces: 


¢ RNIO must be specified so that the ACF/VTAM I/O trace can function 
for an NCP or for a peripheral physical unit. 


¢ IO or IOP must be specified so that the GIF I/O trace can function for a 
channel-attached device. 


¢« USR must be specified so that the ACF/VTAM internal trace, 
ACF/VTAM buffer contents trace, NCP line trace, and SMS buffer usage 
trace can function. 


The keywords for formatting ACF/VTAM trace data for printed output are 
similar to the GTF trace options for ACF/VTAM and are listed under 
“Formatting Printed Output in OS/VS” below. 


Starting GTF in OS/VS 


GTF must be started before any ACF/VTAM trace can be activated. Unless 
the system programmer has modified the IBM-supplied GTF cataloged 
procedure, the time-stamping option (TIME=YES) should be specificd when 
starting GTF. If the GTF options required for ACF /VTAM traces were not 
stored by the system programmer on SYS1.PARML.IB, the operator is prompted 
to supply these options when GTF is started. 


For information on starting GTF and on altering the IBM-supplied GTF 
cataloged procedure, see the service aids manual for your cperating system. 


Formatting Printed Output in OS/VS 


To print ACF/VTAM trace output, use the PRDMP service aid. The PRDMP 
(HMDPRDMP in OS/VS1 or AMDPRDMP in OS/VS2) service aid prints ail 
GTF trace data, including the ACF/VTAM trace data. he operator can 
format the trace data by specifying the following keywords in the PRDMP 
EDIT control statement: 


e IO specifies formatting of all I/O trace records for channel-attached 
devices. 


© TO=(cuul,cuu2, ... ,cuu50) specifies formatting of I/O trace records for 
channel-attached devices with the channel device names cuu/, cuu2,, and so 
_ on, up to a maximum of 50 devices. | 


« RNIO specifies formatting of the I/O trace records for an NCP or a 
peripheral physical unit. 


« USR=([,CLO1][,TPIO][,LINE]) specifies formatting of the buffer 
trace recorded at the user’s buffers (CLO1), before leaving the 
ACE/VTAM transmission subsystem component (TPIO), or the NCP line 
trace (LINE). See the system programmer’s guide for your operating 
system for a full explanation of the CLO1, TPIO, and LINE options of the 
USR keyword. If more than one option is coded, separate them with 
commas. 


¢ USR=(CLO02) specifies formatting of the SMS buffer usage trace. 


For a complete description of the PRDMP service aid, see the system 
programmer’s guide for your operating system. 


Recording and Printing Trace Records and Tuning Statistics in VSE 
In VSE systems, the ACF/ VTAM trace print utility runs as a subtask under 
ACF/VTAM or as a job step under VSE. You can start printing in one of two 
ways: , | | 


* Usea separate job step, whether ACEF/ VTAM is active or not. 


« Use the MODIFY TPRINT command while ACF/VTAM is active, as 
described in the section on the MODIFY TPRINT command in Chapter 4. 


Either method can. be used to print: | 
¢ Specific buffer, I/O, or line trace records, or tuning statistics 


e All buffer, I/O, or line trace records, or tuning statistics 
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e All trace records 


e Trace records of specified types within a selected time interval during which 
the tracing occured 


For | a trace printout, SYSLST must be assigned to a printer, tape, or disk with 
the name IJSYSLS. 


The ACF/VTAM trace utility records trace records in wraparound fashion 
either in main storage or in a trace file assigned to a disk or tape. If the trace 
file is on a disk or tape, the operator is notified when the end of the trace file is 
reached. When a trace file is full, or the main storage buffer (when no file is 
used) is full, the oldest records are overlayed by new trace records. Therefore, 
if trace data is being produced faster than TPRINT can print it, trace data is 
lost due to wraparound. 


If SYSOO1 is assigned to a tape device, ensure that an unlabeled scratch tape is 
mounted and ready before entering the first MODIFY TRACE command. 


Starting and Canceling of Printing Using a Job Step 
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To start printing using a job step, assign a SYSLST disk, tape, or printer to a 
VSE partition. Execute the job step by using the EXEC TPRINT statement. A 
size parameter is not needed because the storage required is a minimal partition. 


When printing is done using a job step, the trace print utility handles a trace file 
on a disk device differently from a trace file on tape. 


If ACF/VTAM is active when TPRINT is requested and if the trace file is on a 
disk device, trace recording is suspended. For the ACF/VTAM internal trace, 
either stop the trace or switch the trace recording to an internal trace table. 


If the trace file is on a tape, ACF/VTAM prompts the operator with the 
message 5K02A, “OPTION TO REPLACE TRFILE TAPE ON SYS001.” The 
operator can enter a null character string, or specify the CANCEL or NEWTAP 
options, with the following results: 


null character string 
lf no option is specified, replacement of the tape that the operator took 
from ACF/VTAM is deferred. External recording of all ACF/VTAM 
traces is stopped temporarily. ACF/VTAM does not attempt to reopen the 
trace file until the next MODIFY TRACE command is entered. 


CANCEL 
specifies that ACF/VTAM’s trace recording is to be canceled because the 
operator took the tape from ACF/VTAM and did not replace it. External 
recording of all ACF/VTAM traces is stopped and cannot be resumed 
unless ACF/VTAM is restarted. 


NEWTAP 
specifies that the operator has moved the tape to the trace print SYSO04 
unit and mounted a new tape for ACF/VTAM. ACF/VTAM records trace 
data on the new volume. | 


The operator can select a snapshot print of the contents of ACF/VTAM’s main 
storage trace buffers containing the most recently recorded trace records, 
without suspending current trace recording. A snapshot print of ACF/VTAM’s 
internal trace buffer is not available. The operator is prompted to select a 
snapshot print if SYSOO1 is assigned to a file. 


If ACF/VTAM is not active, the operator can use the trace print utility if 
SYS004 is assigned to a disk file or tape. 


The operator can cancel the trace print by entering CANCEL when 
ACF/VTAM issues prompting messages, or by canceling the partition in which 
the trace print utility is running. 


The operator can also enter the trace print options as described in the MODIFY 
TPRINT section of Chapter 4. 


Examples of Using the Trace Print Utility 


Tuning Statistics 


The following examples show how the trace print utilty can be used to print 
trace records. 


To print all buffer contents, 1/O, and line trace records, and tuning statistics, 
and erase the records after printing, enter: 


PRINT CLEAR=YES 


To print specific buffer contents trace records, all I/O trace records, and tuning 
Statistics for NCPOO1, enter: 


PRINT BUF=name,name,name, [O=ALL,TNST=NCPO001 


To print all buffer contents trace records and all [/O trace records, and to 
preserve the trace records, enter: 


PRINT BUF=ALL,IO=name,name,CLEAR=NO 


To print specific NCP line trace records recorded from 6:00 p.m. to 6:05 p.m. 
Greenwich Mean Time, enter: 


PRINT LINE=name,name, INTERVAL=(18:00:00,18:05:00) 


To print specific buffer contents trace records and I/O trace records, and to be 
prompted for additional entries on the next line, enter: 


PRINT BUF=name,name,!O=name,name,name,name, 


ACF/VTAM tuning statistics can be used to gather information on 
communications between ACF/VTAM and a communication controller or on 
communications between ACF/VTAM and a SNA cluster controller. These 
Statistics can be used to adjust ACF/VTAM and NCP variables to improve 
performance. The gathering of tuning statistics is started with the MODIFY 
TNSTAT command and terminated with the MODIFY NOTNSTAT command. 
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TOLTEP 


Displaying NCP Storage 


—~§2 


If this facility is to be used, the TNSTAT start option must have been specified 
when ACF/VTAM was started. Additionally, in an OS/VS system, the System 


Management Facility (SMF) must have been included in the system during 


system generation. > 


For more information on using tuning statistics, see the ACF/VTAM Planning 
and Installation Reference manual. 


The teleprocessing online test executive program (TOLTEP) is a component 
of ACF/VTAM that is used to test selected hardware in an ACF/VTAM 
domain. This section contains information on how to invoke TOLTEP either 
from the operator’s console or from a terminal in the ACF/VTAM domain. 
For details on how to use TOLTEP and the types of terminals that can 
invoke TOLTEP, see ACF/VTAM Diagnosis Guide. The MODIFY TEST 
command is used to start TOLTEP. In general, TOLTEP should be invoked 
from a terminal in the domain rather than from the operator’s console; this 
avoids the inconvenience of running both TOLTEP and the rest of the 
system from the console. If TOLTEP is to be invoked by a terminal user and 
if a logon message for TOLTEP has been defined by the system programmer, 
a terminal user can enter that message to log on to TOLTEP and initiate 
testing of selected devices from the terminal. Alternatively, the ACF/VTAM 
operator can log the terminal onto TOLTEP by using the command: 


VARY NET,LOGON=ISTOLTEP,ID=terminal name 


If TOLTEP is invoked by a terminal user, the user must specify the terminals 
to be used or tested, and then TOLTEP asks the ACF/VTAM operator for 
permission to use the specified terminals. Before giving TOLTEP permission 
to use or test terminals, be certain that the terminals named in the request are 
those that are supposed to be tested, and be certain that those terminals are 
not in session with an application program. 


Notes: 


1. Terminals should not be activated or deactivated while TOLTEP is using 
them. 


2. Although TOLTEP can be invoked from the operator’s console, it cannot 
be used to test the operator’s console itself. Only selected hardware that 
is part of the ACF/VTAM domain can be tested by TOLTEP. See 
ACF/VTAM Diagnosis Guide for a list of the devices that can be tested 
by TOLTEP. 


The storage contents of an NCP’s communication controller can be displayed 
at the ACF/VTAM operator’s console. Up to 256 bytes beginning at any 
address within the communication controller can be dynamically displayed. 
To display NCP storage contents, use the DISPLAY NCPSTOR command. 


Changing the Suppression Level of ACF/VTAM Messages 


ACF/VTAM allows most classes of its messages to be suppressed. Message 
suppression can be used to adjust the amount of information the operator 
receives from ACF/VTAM to suit the needs of the operator. 


Messages are divided into these classes (in order, from lowest suppression level 
to highest): 


e Informational 
e Warning 

e Normal 

e Serious 


e Unsuppressible 


The categories of messages to be suppressed can be specified, either when 
ACF/VTAM is started or later, with the MODIFY SUPP command. 
Unsuppressible messages cannot be suppressed. Examples of such messages are 
those that solicit information from the operator, and messages that are 
responses to DISPLAY commands. 


For more information on ACF/VTAM message suppression classes, see 
ACF/VTAM Messages and Codes. | 


Attaching and Detaching Subtasks (VSE Only) 


In VSE systems, the MODIFY ATTACH and MODIFY DETACH commands 
make it possible to attach or detach an IBM subsystem or program (such as 
BTP or SSS) as a subtask of ACF/VTAM. To determine whether a particular 
program can be run as a subtask, see the system programmer’s guide for that 
program. 


Changing a Logical Unit’s Cryptographic Capability (OS/VS 
Only) 


In OS/VS systems, if the Encrypt/Decrypt Feature of ACF/VTAM is installed, 
the cryptographic capability of the logical unit can be raised for future sessions 
by entering the MODIFY ENCR command. For more information on the 
Encrypt/Decrypt Feature of ACF/VTAM, see ACF/VTAM Programming. 
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Chapter 3. Backup and Recovery Procedures 


This chapter provides information on backup and recovery actions an operator 
can take when various types of resources fail in the network. The types of 
failures discussed are: 


e NCP failures: 

« Host failures within a single domain 
e Route failures 

e Link failures 

e Session setup failures 


e Failures involving multiple domains 


For information on specific ACF/VTAM operator messages (including 
suggested operator and system programmer responses to the messages), see 
ACF/VTAM Messages and Codes. For information on diagnosing 
ACF/VTAM problems, see ACF/VTAM Diagnosis Guide. 


Error Recovery Procedures for an NCP Failure 


SSCP-to-NCP Session Recovery 


To use the services of ACF/VTAM, an NCP must have a session with 
ACFE/VTAM'’s SSCP. When an SSCP-to-NCP session fails, the services 
provided by the SSCP on behalf of the NCP’s physical units and logical units 
cease. The NCP goes through automatic network shutdown with respect to 
ACF/VTAM and any resources activated by ACF/VTAM. LU-to-LU sessions 
involving the peripheral devices attached to the communication controller might 
be ended disruptively by automatic network shutdown, depending on how the 
NCP supports each device. As soon as the SSCP-to-NCP session has been 
restored, attempts can be made to recover the disrupted sessions. 


ACF/VTAM automatically attempts logical (session) recovery for an NCP by 
trying to reestablish the SSCP-to-NCP session, possibly using another route if 
one is available within the SSCP’s class of service. If, however, the availability’ 
of virtual routes depends on a physical recovery of some portion of the domain | 
and that recovery fails, the SSCP-to-NCP session recovery remains pending 
indefinitely. As with NCP activation, however, the ACF/VTAM operator is 
informed of the queued route selection request. The operator can then cancel 
this request by deactivating the NCP. 


After re-establishing the SSCP-to-NCP session, ACF/VTAM sends two SNA 
requests, ACTPU(ERP) and ACTLU(ERP), to the NCP’s physical units and 
logical units. If these resources support these SNA commands, their LU-to-LU 
sessions that survived the NCP’s automatic network shutdown procedure remain 
active, and the existence of these sessions is reported to ACF/VTAM. 


The SSCP will lack some information about these sessions, such as the identity 


of the other session partner and the session identifier. This means that 
DISPLAY commands will provide incomplete information about these sessions. 
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(For example, a DISPLAY ID=logical unit name command will indicate that an 
active session exists but the ALLOC field will be blank, indicating that the 
session partner is unknown.) It also means that when using the VARY TERM 
command for one of these sessions, the command cannot refer to the session 
partner that is unknown to ACF/VTAM. Specifically, the PLU, SLU, or LU 
operand must name the session partner within the domain of the operator 
entering the command. Also, the TYPE=UNCOND or TYPE=FORCE 
operand must be specified. 


Physical units that do not support ACTPU(ERP) break existing sessions of their 
subordinate logical units whenever the physical units are activated by an SSCP. 
Logical units that do not support ACTLU(ERP) break their existing sessions 
whenever the logical units are activated by an SSCP. Thus, if these SNA 
commands are not supported by the physical units and logical units, LU-to-LU 
sessions are terminated disruptively upon activation of these resources by the 
SSCP when the NCP is recovered. 


Note: The session disruption for physical units and logical units that do net 
support the ACTPU(ERP) and ACTLU(ERP) requests occurs whenever the 
SSCP is able to recover from the loss of its SSCP-to-NCP session. This could 
occur because the SSCP is able to physically recover a failed part of the route 
to the NCP (for example, by reactivating a link station along the route). It 
could also occur because of the availability of another route to the NCP. This 
session disruption can he controlled, if desired, by ensuring that no more than 
one route is made available to the SSCP for establishing its SSCP-to-NCP 
session. 


Migration Considerations: ACF/VTAM sends ACTPU(COLD) and 
ACTLU(COLD) requests to peripheral physical units and logical units attached 
to an ACF/NCP/VS Release 2, because ACF/NCP/VS Release 2 does not 
support ERP responses to ACTPU(ERP) and ACTJL.U(ERP) requests directed 
to its peripheral nodes. Therefore, existing sessions involving these physical 
units and logical units are disrupted, even if the physical units and logical units 
support the ACTPU(ERP) and ACTLU(ERP) requests. 


NCP 


The failure of an NCP in a communication controller is discovered by 
ACF/VTAM from the resulting failures of the link stations in adjacent nodes 
that represent the attachments to the failed NCP. (ACF/VTAM receives the 
link station failure notifications as a result of having activated each link station.) 
Specifically, ACF/VTAM might find the need to reload the communication 
controller attached to the failed link stations during the recovery procedures for 
the link stations. 


Depending on how the AUTODMP and AUTOIPL operands are specified in an 
NCP definition, ACF/VTAM can either dump and reload the NCP 
automatically or give the operator control of these operations. If 
AUTODMP=NO or AUTOIPL=NO is specified or assumed by default in the 
NCP definition, the operator is prompted for permission to dump or reload the 
NCP. In this case the operator can also specify the adjacent link station 
through which the dump or reload is to be done, or can specify that 
ACF/VTAM is to make a selection without regard to previous dump or load 
station specifications. If the operator does not specify a link station, the dump 
or load station specification in effect when the NCP was activated is used. If 


Option to Dump 


no specification was in effect when the NCP was activated, ACF/VTAM makes 
a selection. 


If an NCP is owned by only one SSCP, the dumping and reloading of the NCP 
can either be done automatically (through AUTODMP and AUTOIPL) or be 
controlled by the domain operator. If the system programmer has not specified 
automatic dumping and reloading, ACF/VTAM displays the “OPTION TO 
DUMP” message (ISTO95A in OS/VS or 5A95A in VSE) and “OPTION TO 
RELOAD” message (IST284A in OS/VS or 5C84A in VSE), to which the 
operator can give the appropriate response. The possible responses to these 
messages are described in ACF/VTAM Messages and Codes. 


If an NCP is shared by more than one SSCP, it is recommended that the 
dumping and reloading of that NCP be controlled by the domain operators. If 
automatic dumping and reloading are specified, or if the domain operators reply 
to the “OPTION TO DUMP” and “OPTION TO RELOAD” messages without 
coordinating their actions, it is possible that two SSCPs will try to dump or load 
the same NCP at the same time. The recommended recovery sequence after an 
NCP failure is to respond “YES” to any “OPTION TO DUMP” and “OPTION 
TO RELOAD” messages in only one SSCP and withhold the responses to the 
corresponding messages in airy other SSCPs sharing ownership of the NCP until 
the dump or load operation is completed. After completion, respond “NO” in 
the remaining SSCPs. Once one SSCP has completed an NCP reload, the 
“NO” response to the “OPTION TO RELOAD” message in the remaining 
SSCPs causes ACF/VTAM in these SSCPs to try to recover all of the adjacent 
link stations that were reported inoperative as a result of the NCP failure. 


If AUTODMP=NO is specified or assumed by default in the definition of an 
NCP, the “OPTION TO DUMP” message (ISTO95A in OS/VS or 5A95A in 
VSE) is produced during error recovery for that NCP. This message allows the 
operator to specify whether the NCP is to be dumped by this SSCP. See 
ACF/VTAM Messages and Codes for more information on this message. 


If the operator specifies that the NCP is to be dumped by this SSCP, 
ACE/VTAM dumps the NCP through an adjacent link station. The error 
recovery continues after a successful dump. 


Optionally, the operator can specify the name of the adjacent link station 
through which the dump operation is to be performed, thereby overriding the 
dump station specification currently in effect (if any). The operator can also 
cancel the specification currently in effect. In either case, the operator’s 
specification applies only for this particular dump. “Dumping an NCP” in 
Chapter 2 describes how the current dump station specification was established 
and the requirements for using a link station for dumping an NCP. 


If there is no dump station specification currently in effect, or if the operator 
cancels the specification, ACF/VTAM selects a channel link station, if one is 
available. If no channel link station is available, ACF/VTAM uses any 
available SDLC link station. 


If the operator specifies that no dump is to be performed by this SSCP, the 
error recovery continues as if the NCP had been successfully dumped. The 
NCP is not deactivated. Use a VARY INACT command to deactivate the 
NCP, if desired. 


Chapter 3. Backup and Recovery Procedures 57 


Option to Reload 


if AUTOIPL is not specified in the definition statements for an NCP, the 
“OPTION TO RELOAD” message (IST284A in OS/VS or 5C84A in VSE) is 
produced during error recovery for that NCP. This message allows the operator 
to specify whether the NCP is to be reloaded by this SSCP. See ACF/VTAM 
Messages and Codes for more information on this message. 


If the operator specifies that the NCP is to be reloaded by this SSCP, 
ACF/VTAM reloads the NCP through an adjacent link station, unless the 
adjacent link station is a channel link station and the NCP has already been 
successfully reloaded by another SSCP. The error recovery continues after a 
successful reload. 


Optionally, the operator can specify the name of the adjacent link station 
through which the reload operation is to be performed, thereby overriding the 
load station specification currently in effect (if any). The operator can also 
cancel the specification currently in effect. In either case, the operator’s 
specification applies only for this particular reload. “Loading an NCP” in 
Chapter 2 describes how the current load stetion specification was established 
and the requirements for using a link station for loading an NCP. 


If there is no load station specification currently in effect, or if the operator 
cancels the specification, ACF/VTAM selects a channel link station, if one is 
available. If no channel link station is available, ACF/VTAM uses any 
available SDLC link station. 


If the operator specifies that no reload is to be done by this SSCP, the error 
recovery continues, provided that the NCP has been successfully reloaded by 
another SSCP. If the NCP has not been reloaded, the recovery does not 
complete, and failing adjacent link stations are deactivated. As discussed under 
““SSCP-to-NCP Session Recovery” in this chapter, the session recovery remains 
pending, waiting for a route to become operative. Use a VARY INACT 
command to deactivate the NCP, if desired. 


Switching to Another Channel or Communication Controller 


The operator might find it necessary to reactivate an NCP in the same or a 
different communication controller. This could occur when: 


e The channel to a channel-attached communication controller fails and the 
operator switches to another channel. If a communication controller is 
equipped with a type 3 channel adapter, the switch to an alternate channel 
is done automatically, without interrupting NCP operation. In this case 
there is no need to reactivate the NCP. 


e A failure occurs in a communication controller and the operator has a 
backup communication controller available, either with equivalent 
cross-subarea links and peripheral devices or with the capability to switch 
cross-subarea and peripheral links to the backup communication controller. 


After switching to another channel or communication controller, the operator 
enters the VARY ACT command to reactivate the NCP major node and, 
optionally, to provide either or both of the following: 


e A new channel device name on the U operand, if the communication 
controller is channel-attached 


e New link station names on the RNAME operand, if the communication 
controller is attached through SDLC links different from those used before 
switching to the backup communication controller 


As a result of the VARY ACT command, ACF/VTAM loads the NCP, if 
necessary, and activates it. The operator can then enter more ACF/VTAM 
commands to restore the minor node status in the NCP’s configuration. 
Optionally, the configuration restart facility can be used when activating the 
NCP to restore the minor node status. See “Configuration Restart” elsewhere 
in this chapter for information on the requirements for using configuration 
restart. 


Error Recovery Procedures for an ACK/VTAM Host Failure 


If ACF/VTAM fails, the operator can try to restart ACF/VTAM. The 
configuration restart facility can be used to restore the domain’s resources (but 
not LU-to-LU sessions) to their status prior to the failure, assuming that the 
system programmer has provided for the use of this facility in the resource 
definitions. In a multiple-domain network, the SSCPs in other domains can take 
over ACF/VTAM’s resources, as described in ‘Error Recovery Procedures for 
Failures in a Multiple~-Domain Network” elsewhere in this chapter. 


Configuration Restart 


Configuration restart is an ACF/VTAM facility that maintains certain status 
information about ACF/VTAM resources. In general, this information includes . 
active/inactive status aud operator-specified values of activation and operating 
parameters. When restarting ACF/VTAM after a halt or failure, or when 
reactivating an individual major node after a deactivation or failure, 
ACF/VTAM can use this information to restore the resources to their status 
prior to the deactivation or failure. 


Restarting Viajer Nedes 


The system programmer can define a NODELST file in which to record the 
names of major nodes, path definition sets, and dynamic reconfiguration files 
(DRDS files) that are active in the domain, as described in ACF/VTAM 
Planning and Installation Reference. Information in the NODELST file can 
later be used when restarting ACF/VTAM to reactivate these major nodes, 
path definition sets, and dynamic reconfiguration files (DRDS files) without 
individual operator commands. This is done by specifying the name of the 
NODELST file as the value for the CONFIG start option. 


(in OS/VS) or 5E25I (in VSB), indicating that an OPEN failure occurred on 
the NODELST file with VSAM error codes X*04’ and X‘74’, the operator 


If. in response to an attempted restart, ACF/VTAM displays message IST425I | 
should use the Access Method Services VERIFY operation (see OS/VSI1 Access ° | 
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Method Services, GC26-3840, OS/VS2 Access Method Services, GC26-3841, or 
DOS/VS Access Method Services User’s Guide, GC33-5382) to ensure that the 
named NODELST file is properly closed. If the operator again tries the restart 
without first performing the VERIFY operation, this message is not repeated, 


but some of the information in the file might be lost. 


The system programmer can define configuration restart files, as described in 
ACF/VTAM Planning and Installation Reference , in which to record status 
information about minor nodes. When restarting ACF/VTAM after a halt or 
failure, or when reactivating an individual major node after a deactivation or 
failure, ACF/VTAM can use this information to restore the minor nodes to 
their status prior to the deactivation or failure. 


Every time the operator changes the status of a minor node, the change is 
recorded in the configuration restart file (if one exists) for the corresponding 
major node. Note that configuration restart files are not updated to reflect 
changes to resources acquired with the VARY ACQ command, or resources 
added or deleted through the use of the dynamic reconfiguration function. 


Information in configuration restart files can be used when restarting 
ACF/VTAM by specifying the WARM start option. If the WARM start option 
is specified, ACF/VTAM restores the status of the minor nodes of each major 
node named in the file specified by the CONFIG start option. However, if a 
major node’s configuration restart file has never been used for status recording, 
or if the major node has no configuration restart file, the minor node status 
information for that major node is set to the defined initial status. That is, the 
activation proceeds as if a VARY ACT,SCOPE=U command had been 
specified for the major node. 


if the WARM start option is not specified when restarting ACF/VTAM, 
ACE/VTAM restores the major nodes’ minor nodes to their defined initial 
status. That is, the activation proceeds as if a VARY ACT,SCOPE=COMP 
command had been specified for each major node. The previous status 
information in any configuration restart files for these major nodes is deleted. 


The configuration restart files can also be used when individually reactivating a 
major node, by specifying the WARM operand on the VARY ACT command. 
If the WARM operand is specified, ACF/VTAM restores the minor nodes to 


the status recorded for them in their configuration restart file. However, if the 


major node’s configuration restart file has never been used for status recording, 
or if the major node has no configuration restart file, ACF/VTAM rejects the 
VARY ACT command. 


If the WARM operand is not specified on a VARY ACT command for a major 
node, ACF/VTAM sets the status of the minor nodes according to the specified 
value of the SCOPE operand. If the SCOPE operand is not specified, the 
default value of SCOPE=COMP is used. The previous status information in 
any configuration restart file for the major node is deleted. 


Restart Considerations 


When using the configuration restart facility, the operator must be aware of the 
following restart considerations to ensure a satisfactory restart: 


¢« Because the status of any ACF/VTAM commands being processed at the 
time of a failure cannot be predicted, the ACF/VTAM operator should use 
DISPLAY commands to determine whether any commands being processed 
at the time of failure need to be entered again. 


¢ The configuration restart facility does not record status information for 
resources acquired with the VARY ACQ command, or for resources added 
or deleted by the dynamic reconfiguration function. The operator must use 
ACF/VTAM commands to restore such resources to their previous status, if 
desired. 


e After a failure in ACF/VTAM, the host processor, or the host operating 
system, and the subsequent restart of the domain, communication might not 
be possible with lines or terminals that were being tested with online test 
programs (OLTs) when the failure occurred. After the status of the domain 
is reestablished, TOLTEP should be run again for those lines or terminals. 


¢ If a logical unit is restarted and if that logical unit has a controlling 
application program associated with it (whether through the LOGAPPL 
operand of its definition statement, through a VARY LOGON command, or 
through the LOGON operand of a VARY ACT or VARY ACQ command), 
ACF/VTAM automatically generates a logon for that logical unit to the 
controlling application program, whether or not the logical unit was in 
session with that application program when the failure occurred in the 
domain. 


e When an NCP is defined or activated, one or more link stations in adjacent 
NCPs can be specified for automatic activation when the NCP is activated. 
(Specifically, this involves the CUADDR and RNAME operands of the 
PCCU macro in the NCP definition, and the U and RNAME operands of 
the VARY ACT command.) Because these adjacent link stations are 
associated with the NCP being activated for purposes of automatic 
activation, reactivation of the NCP with the WARM option (either at start 
time or on the VARY ACT command) causes ACF/VTAM to 
automatically reactivate the link stations. This is true even if the link 
stations in the adjacent NCPs were inactive at the time of the failure. 


Migration Considerations: Configuration restart files defined for NCP major 
nodes in a previous release of ACF/VTAM cannot be used for ACF/VTAM 
Release 3. For information on the definition requirements for configuration 
restart files, see ACF /VTAM Planning and Installation Reference. 


Chapter 3. Backup and Recovery Procedures 61 


Switching to a Backup Host Processor 


If configuration restart files are defined, ACF/VTAM provides some support 
for switching one or more major nodes from a failing host to an ACF/VTAM 
in a backup processor. This kind of backup involves moving the VSAM 
configuration restart file for each major node to be switched. The NODELST 
file also can be moved, if desired. The primary and backup processors must 
meet these conditions: | 


¢ Both host processors must have the same levels of ACF/VTAM and VSAM 
installed, although they need not have the same operating system. 


¢ The ACF/VTAM major node definitions and their corresponding hardware 
configurations must be the same in both systems. (Physically switching the 
hardware connections from one system to another would satisfy the 
requirement for matching hardware configurations. ) 


¢ The MAXSUBA value must be the same in both ACF/VTAM systems. 


The VSAM files are moved by creating the files and a user catalog on the 
primary system and then using Access Method Services to ‘IMPORT 
CONNECT?’ the user catalog (and all of its cataloged files) in the backup 
system. (See OS/VSI Access Method Services, GC26-3840, OS/VS2 Access 
Method Services , GC26-3841, or DOS/VS Access Method Services User’s 
Guide , GC33-5382.) The backup system can then gain access to the primary 
system’s NODELST and configuration restart files through either a shared disk 
storage arrangement or by physically moving the VSAM volumes containing the 
user catalog and files. 


If ACF/VTAM is restarted in the backup system after moving the VSAM 
volumes, the appropriate job control language for the VSAM user catalog and 
files can be included in the ACF/VTAM start procedure at that time. If, 
however, one or more major nodes are to be switched without restarting 
ACF/VTAM in the backup system, the job control language must be included 
when ACF/VTAM is started, sometime before the switch is made. For more 
information on including this job control language, refer to ACF/VTAM 
Planning and Installation Reference. 


Reconfiguration for a Multiprocessor in MVS_ 
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In a suitably prepared multiprocessor, one processor can back up the other. 

The procedure required to do the necessary reconfiguration varies, depending on 
whether the attached devices are symmetric (devices that are attached to all 
processors in a multiprocessor) or asymmetric (devices that are attached to only 
one processor in a multiprocessor). The following guidelines might be useful 
when developing operator procedures for reconfiguring a specific 

multiprocessor: 


e In most cases, recovery for symmetric devices is provided automatically. 
For a symmetric communication controller equipped with a type 3 channel 
adapter, the system VARY command can be used to bring the channel 
paths offline when doing a system reconfiguration. This is not necessary 
during a recovery from a processor failure, because the channel paths on the 
failing processor automatically go offline. 


e Asymmetric devices must be equipped with a 2-channel switch to allow 
backup by an alternate processor. 


—- If an NCP in an asymmetric communication controller has not been 
deactivated by the ACF/VTAM error recovery procedures, use the 
VARY INACT,I or VARY INACT,F command to deactivate the NCP. 


— If an asymmetric physical unit or logical unit has not already been 
deactivated by the ACF/VTAM error recovery procedures, use the 
VARY INACT,I or VARY INACT,F command to deactivate the 
resource, or to deactivate its major node. 


— Switch the device to the alternate processor. 


- For each device affected by the physical switching operation, use the 
system VARY command to bring the channel paths online for each 
device and, if necessary, to bring previous channel paths offline. 


- Use the VARY ACT command to reactivate the appropriate major and 
minor nodes. Configuration restart files can be used as described 
elsewhere in this chapter. 


- Restart user sessions as appropriate. 


Error Recovery and Verification Procedures for Routes 


| Route Failures 


Route Activation Failures 


An explicit route fails if a physical element of the explicit route (line, channel, 
host processor, communication controller, and so on) fails or is deactivated. An 
ACF/VTAM operator is informed of a failure of such a physical element only if 
it was activated in the ACF/VTAM domain. However, an ACF/VTAM | 
operator is informed of an explicit route failure (by message IST526I [in 
OS/VS] or 5F261 [in VSE]) for any route ending in the operator’s 
ACF/VTAM host, and is told which virtual routes are affected by the explicit 
route failure. Besides identifying the failed route, ACF/VTAM reports the 
location of the outage by identifying the subarea that detected the outage, the 
affected transmission group, and the subarea node at the other end of this 
transmission group. 


A virtual route fails when the explicit route to which it is assigned becomes 
inoperative. When a virtual route failure disrupts a session, the session partners 
are notified of the session failure. The session partners can then decide whether 
or not to try to restart the session (perhaps using another route). 


As stated in Chapter 2, ACF/VTAM automatically activates explicit and virtual 
routes as they are requested for sessions. Such route activations can fail for 
various reasons, the most common being improperly defined routes (in the 
Various intermediate nodes and the other end node) and inoperative rouies 
(because of failed or inactive links or nodes). When ACF/VTAM initiates a 
route activation and the activation fails, ACF/VTAM displays a message 
(IST522I [in OS/VS] or 5F22I [in VSE] to inform the operator of the 

failure. This message identifies the explicit or virtual route, the two end nodes, 
and the reason for the failure. Because an explicit route activation can fail at 
an intermediate node along the route, this message also indicates (for an explicit 
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route activation failure) the subarea node rejecting the activation, the 
transmission group over which the activation request could not be forwarded or 
the transmission group over which the activation request was received, and the 
subarea node at the other end of this transmission group. 


While the operator probably cannot correct route definition problems in 
intermediate nodes (because such definitions require an NCP generation to 
change them), route definition problems in another ACF/VTAM end node and 
inoperative route problems can be corrected. Coordination with operators in 
other domains is necessary, except in the case of inoperative routes that are 
entirely within a single domain. 


Note that when a session requests a route and there are no routes that are both 
defined and operative within the requested class of service, no route activations 
are attempted and therefore no route activation failure messages appear. The 
operator is informed of the session setup failure, however, in message IST5211 
(in OS/VS) or 5F22I (in VSE), with an indication that no routes were defined 
or no routes were operative. (This message also appears if a session setup fails 
because all attempted route activations failed.) 


An activation request can be received from the other end of a route for an 
explicit or virtual route that has not been defined to ACF/VTAM, or that has 
been defined in a way incompatible with the received route activation request. 
Such a route activation request is rejected and, because operator action might 
be required to activate a path definition set that properly defines the explicit or 
virtual route (so that future route activation requests can be accepted), a 
message (IST522I [in OS/VS] or 5F22I [in VSE]) is displayed to inform 

the operator of the problem. This message identifies the explicit or virtual 
route, the two end nodes, and the reason for the activation rejection. 


The TEST operand of the DISPLAY ROUTE command allows an operator to 
cause any or all known explicit routes between the host subarea and any 
destination subarea to be tested for the route’s ability to transfer data between 
the subareas. The operator can specify the testing of the explicit routes 
associated with a particular explicit route number, virtual route number, or class 
of service name. The operator can also specify the testing of all routes to a 
destination subarea. For route verification, ACF/VTAM sends a route test 
request on all of the specified explicit routes to the specified destination 
subarea. If an explicit route is both defined and operative over its entire length, 
the subarea at the other end replies to ACF/VTAM, which in turn tells the 
ACF/VTAM operator (in message [ST533I [in OS/VS] or 5F331 [in VSE}) 
that the explicit route completed the test successfully. If the route test request 
is able to traverse only part of the explicit route (for example, because of an 
inoperative physical element or because the route was improperly defined in 
some node), the subarea that detects the problem notifies ACF/VTAM, which 
in turn tells the ACF/VTAM operator (in message IST533I or 5F331 of the 
route test failure. This multiple-line operator message identifies the subarea 
reporting the problem, the transmission group over which the route test request 
could not be forwarded or the transmission group over which the route test 
request was received, and the subarea node at the other end of this transmission 
group. The notification thereby isolates the problem to a specific transmission 
group or subarea. The subarea node that detects the route test failure also 
notifies all of its owning SSCPs that a route verification test failed, and 
identifies the subarea that originated the test. The SSCPs in turn pass this 


informa‘ion to their domain operators so that corrective action can be taken to 
make the route operative. (Note that there can thus be two failure notifications 
in a given host processor if the route test failure occurs in the domain 
originating the test. See the explanation of message IST533I or 5F33I in 
ACF/VTAM Messages and Codes for further details of such route test failure 
notifications. ) 


Migration Considerations: If the route being tested contains a node that does 
not support the route verification test (such as ACF/NCP/VS Release 2 or 
ACF/VTAM Release 2), the route test will fail (with the reason 
“MIGRATION NODE ENCOUNTERED?” in message IST533I or 5F33I1 at 
that node. This does not necessarily mean that the route is unusable; it only 
means that the route cannot be tested beyond this particular node. 


Error Recovery Procedures for Link Failures 


Cross-Subarea Link Failures 


Generally speaking, backup for cross-subarea link failures is best handled by the 
use of multiple-link transmission groups, parallel transmission groups, and 
multiple routes. All cross-subarea SDLC link stations can be individually 
activated and deactivated as needed, and therefore parallel connections to an 
adjacent subarea can be activated concurrently, or some can be activated in the 
event of failure of others. The link and link station definitions and activation 
procedures are the same either way. 


While switched cross-subarea links are not supported directly by the NCP, a 
switched link can be used as a backup to a nonswitched cross-subarea link by 
defining the backup link as a nonswitched link and manually establishing the 
switched connection before the NCP’s “enable timeout” expires. From this 
point, the link can be operated as a nonswitched link. (Such a switched link, of 
course, can also be run as a transmission group in parallel with nonswitched 
transmission groups.) 


Migration Considerations: Because ACF/NCP/VS Release 2 does not support 
parallel transmission groups or multiple-link transmission groups, and because 
backup cross-subarea link stations must be explicitly defined to the NCP, 
backup procedures are quite different from those described above (but are the 
same as they were in previous releases of ACF/VTAM). 


If the SDLC link connecting two communication controllers fails, and one or 
both controllers contain an ACF/NCP/VS Release 2, a backup link can be 
used to reestablish communication as follows: 


1. If the original link and link station are not already inactive, deactivate them. 


2. If the backup link is a switched link, manually establish the connection (as 
described above for NCPs not considered migration-level with respect to 
ACF/VTAM). The backup link is then treated as a nonswitched link. 


Activate the backup link if it is not already active. 


4. Activate the backup link station as follows: 


VARY NET,ACT,ID<=original link station,JRNAME=backup link station 
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ACF/VTAM initially accepts this command, before it can confirm that one or 
both of the connected NCPs is an ACF/NCP/VS Release 2. If ACF/VTAM 
finds, during the activation processing, that neither NCP is an ACF/NCP/VS 
Release 2, the command fails. A message is displayed indicating that a VARY 
ACT command should be entered to directly activate the backup link station 
(that is, the name of the backup link station should be specified for the [D 
operand and the RNAME operand should be omitted). 


To return to the original link, deactivate the backup link and the original link 
station, and then reactivate the original link and link station. 


Backup of links to peripheral nodes of an NCP can be achieved by using 
switched links temporarily until the original links are repaired. There are two 
ways to do this. One way is to use a switched major node in a procedure called 
switched network backup. (The switched network backup procedure is not 
related to the switched network backup feature available on many modenis.) 
The other way does not involve a switched major node; instead a backup 
switched link is defined as a nonswitched link to the NCP, and the NCP is 
dynamically reconfigured to move the affected physical unit from its original 
link to the backup link. 


For switched network backup, ACF/VTAM allows the system programmer to 
define a physical unit and its logical units so that they can use a switched line to 
back up a nonswitched line. To do this, the system programmer defines the 
switched line in an NCP major node, and also defines the physical unit and its 
logical units in the NCP major node under the nonswitched line. The system 
programmer then defines the same logical unit names under a different physical 
unit name in a switched major node. If the physical unit and its logical units 
are active as part of the NCP major node and the nonswitched line fails, the 
ACF/VTAM operator can enter the VARY REL command for the nonswitched 
physical unit. This makes the logical unit names unknown to ACF/VTAM. 
The operator can then activate the switched major node, the backup switched 
line, and then the physical unit (under its backup, or switched, name) and its 
logical units. Later, when the nonswitched line is recovered, the operator can 
go back to it by deactivating the switched major node and then entering the 
VARY ACO command for the nonswitched physical unit. 


For example, suppose that the system programmer has defined an NCP with a 
peripheral physical unit named PU1 under a nonswitched line named LINE]. 
Suppose also that the system programmer has defined a switched major node 
containing the same physical unit, but named PU2, to be used with a switched 
line named LINE2, as shown in Figure 3-1. 


If LINE1 fails, the operator can use the backup switched line by entering 
VARY NET,REL,ID=PU1 and then activating LINE2, the switched major 
node, and PU2 (which is just another name for PU1) and its logical units in the 
usual manner. If LINE1 is restored later, the operator can go back to it by 
deactivating the switched major node, reactivating LINE1, and then entering 
VARY NET,ACQ,ACT,ID=PU1,SCOPE=ALL. 


The other method of peripheral link backup involves defining a switched line as 
a nonswitched line and manually establishing the switched connection between 
the NCP and the peripheral device before the NCP’s “enable timeout”’ expires. 
From this point, the line is operated as a nonswitched line. The operator can 
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Figure 3-1. Switched Network Backup 


then use the dynamic reconfiguration facility to redefine the appropriate 
physical units and logical units under the backup line. 


Refer to the ACF/VTAM Planning and Installation Reference manual for an 
additional discussion of this procedure. 


Error Recovery Procedures for Session Setup Failures 


in many cases, session setup failures are due to problems beyond the control of 
the ACF/VTAM operator (such as faulty session parameters or incorrect route 
definitions). However, one possible reason for a session setup failure is that 
some resource required for the session (such as a path definition set, application 
program, or line) has not been activated. In such cases the operator should 
activate the required resource. 


In a multiple-domain network, session setup for a cross-domain LU-to-LU 
session might fail if the necessary SSCP-to-SSCP session and CDRSC 
definitions are not active. (Note that certain CDRSC definitions can be defined 
automatically, as described in Chapter 2 of this manual and in ACF/VTAM 
Planning and Installation Reference.) Often these failures occur without 
detailed messages to the terminal user that requested the session. 


To aid in problem determination, ACF/VTAM informs the operator designated 
to receive unsolicited messages when any of the following conditions prevent 
setup of an LU-to-LU session: 


e No routes are available within the requested class of service. 
e The destination CDRM is not defined. 
e The necessary SSCP-to-SSCP session is not active. 


« A required cross-domain resource is not defined or not active. 


When a session requests a route and there are no routes that are both defined 
and operative within the requested class of service, or when all attempted route 
activations fail, the operator is informed of the session setup failure in message 
IST5211 (in OS/VS) or 5F211 (in VSE). This message indicates primary and 
sccondary logical units, the class of service name, and the virtual route numbers. 
It also indicates the reason for the session setup failure: whether no routes 
were defined, no routes were operative, or no routes were activated. These 
reasons for failure are hierarchical, in that if any (but not necessarily all) routes 
within the class of service are operative and defined and their activations fail, 
the message reports that no routes were activated (with no indication of other 
routes that might not be defined or operative). Likewise, if there are no routes 
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that are both operative and defined, but one or more (but not necessarily all) 
are defined, the message reports that no routes were operative. Only if no 
routes within the class of service are defined does the message report that no 
routes were defined. | 


The message for the non-routing-related session setup failures informs the 
operator of the name of the resource that prevented successful session initiation 
and the names of the primary and secondary logical units for which the session 
setup failed. The message is displayed in the domain that detected the problem. 
The operator at that domain can then activate the indicated resource so that the 
session setup can be retried. 


Error Recovery Procedures for Failures in a Multiple-Domain 
Network 


When ACF/VTAM is part of a multiple-domain network, the ACF/VTAM 
operator might be called upon to participate in error recovery procedures that 
involve other domains and other domain operators. These error recovery 
procedures include procedures to handle SSCP-to-SSCP session failures and 
SSCP-to-NCP session failures. 


SSCP-to-SSCP Session Failure 


A cross-domain LU-to-LU session requires the existence of a session between 
the SSCPs in the two domains to permit the establishment and termination of 
the |.U-to-LU session. If the SSCP-to-SSCP session fails, the domain operators 
for both SSCPs receive a message informing them of the failure. Existing 
cross-domain sessions can continue undisturbed, but the SSCPs are unable to 
provide full termination services for these sessions. If the VARY TERM 
command is used to terminate a cross-domain session for which there is no 
SSCP-to-SSCP session, the TYPE=UNCOND or TYPE=FORCE operand must 
be specified. 

Yo restart the SSCP-to-SSCP session, the operator of one of the affected SSCPs 
must activate the appropriate external CDRM minor node. It is not necessary 
to deactivate an external CDRM before reactivating it. Deactivation of an 
external CDRM, if requested, terminates all existing cross-domain sessions to 
the domain of the SSCP represented by that external CDRM. After the 
SSCP-to-SSCP session has been restarted, the VARY TERM command is again 
able to provide full termination services for cross-domain sessions to the domain 
of the other SSCP. 


Migration Considerations: Jf a logical unit participating in a cross-domain 
session is attached to an ACF/NCP/VS Release 2, that session wiil be 
disruptively terminated when the SSCP-to-SSCP session is restarted. Also, if 
one of the SSCPs is an ACF/VTAM release prior to ACF/VTAM Release 3, 
an ACF/TCAM release prior to ACF/TCAM Version 2 Release 3, or an 
ACF/VTAME, all sessions between the two domains will be disruptively 
terminated when the SSCP-to-SSCP session is restarted. 


SSCP-to-NCP Session Failure 
In a multiple-domain network, one SSCP can be designated as a backup for 


another SSCP in the network. If an-SSCP is so designated, the operator of that 
backup SSCP might need to take over the resources of an NCP that has lost its 
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session with another SSCP. The operator at a backup SSCP learns that an NCP 
has lost an SSCP either by being notified by the other SSCP’s operator or as 

the result of receiving a “‘lost control point’? message for the NCP from 
ACF/VTAM. 


An ACF/VTAM operator receives a notification message from ACF/VTAM 
only if the SSCP is a shared owner of (that is, only if the operator has 
activated) the NCP whose resources are to be taken over. When an NCP loses 
an SSCP-to-NCP session, the NCP informs its other owning SSCPs (that is, the 
other SSCPs with which it has an SSCP-to-NCP session) about the lost SSCP. 
When ACF/VTAM receives such a notification, it displays the “lost control 
point” message. 


Note: Receiving a “lost control point’? message for an NCP at the backup 
SSCP might not in itself indicate that resource takeover should be performed. 
The SSCP that normally owns the NCP might successfully recover from the loss 
of its SSCP-to-NCP session. If a message is also received at the backup SSCP 
indicating the SSCP-to-SSCP session with the other SSCP was lost, this could 
be taken as additional evidence that resource takeover is required. If there is 
any doubt, consult the operator of the lost SSCP. 


When an SSCP-to-NCP session fails, the SSCP can no longer provide control 
point services for the NCP’s resources. The NCP goes through an automatic 
network shutdown procedure with respect to the lost SSCP and any resources 
activated by that SSCP. LU-to-LU sessions might be disrupted by the 
automatic network shutdown procedure, depending on how the NCP supports a 
given logica] unit. As soon as a logical unit is reactivated by an SSCP, any 
disrupted sessions can be reinitiated. 


There are a number of resource takeover strategies available in ACF/VTAM 
for use in the event of an NCP losing an SSCP. They are discussed in detail 
below, under “Resource Takeover Strategies.”’ 


Resource takeover can be accomplished without disrupting existing sessions 
(that is, those that survive the automatic network shutdown procedure in the 
NCP) of logical units being taken over if the logical units and their physical 
units support the SNA requests ACTPU(ERP) and ACTLU(ERP). 
ACF/VTAM uses these commands when activating physical units and logical 
units, respectively. Physical units that do not support ACTPU(ERP) break 
existing sessions of their subordinate logical units whenever the physical units 
are activated by an SSCP. Logical units that do not support ACTLU(ERP) 
break their existing sessions whenever the logical units are activated by an 
SSCP. Thus, if these SNA commands are not supported by the physical units 
and logical units, LU-to-LU sessions are terminated disruptively upon activation 
of these resources by an SSCP. 


For physical and logical units that support these SNA commands, their existing 
LU-to-LU sessions remain active, and the existence of these sessions is reported 
to the SSCP taking over the physical and logical units. This SSCP might lack 
some information about these sessions, such as the identity of the other session 
partner and the session identifier. This will happen unless the backup SSCP 
originally participated in the establishment of a session as the owning SSCP of 
the other session partner. (For example, if a logical unit is in session with an 
application program in the domain of the SSCP taking over the logical unit, the 
SSCP will continue to have full information about the session.) The lack of full 
session information means that DISPLAY commands will provide incomplete 
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information about these sessions. (For example, a DISPLAY ID=logical unit 


name command will indicate that an active session exists but the ALLOC field 


will be blank, indicating that the session partner is unknown.) It also means that 
when using the VARY TERM command for one of these sessions, the command 
cannot refer to the (cross-domain) session partner that is unknown to 
ACF/VTAM. Specifically, the PLU, SLU, or LU operand must name the 
session partner within the domain of the operator entering the command. Also, 
the TYPE=UNCOND or TYPE=FORCE operand must be specificd. 


Migration Considerations: Existing sessions involving physical units and logical 
units attached to an ACF/NCP/VS Release 2 are disrupted when the physical 
units are activated, even if the physical units and logical units support the 
ACTPU(ERP) and ACTLU(ERP) requests. | 


In addition, ACF/NCP/VS Release 2 does not provide the “lost control point” 
notification discussed above. Notification of a lost SSCP-to-NCP session must 

be provided by the operator of the affected SSCP to the cperator of the backup 
SSCP. 


ACF/VTAM’s shadow resource function enables an SSCP to take over 
ownership of an NCP’s resources without the need for the operator to 
deactivate cross-domain resource definitions, and therefore without the need to 
disrupt existing cross-domain LU-to-LU sessions. 


In a typical multiple-domain network, the resources to be taken over are usually 
already defined to the backup SSCP as cross-domain resources. A resource 
takeover (that is, the activation of a same-domain representation of an 
already-active cross-domain resource) does not result in a duplicate name 
situation because ACF/VTAM recognizes this situation and deals with it in the 
following manner. 


When a logical unit and a cross-domain resource have the same name, 
ACF/VTAM assumes that they represent the same physical resource. When 
the logical unit definition is active, the resource is considered part of the SSCP’s 
own domain, and when the cross-domain resource definition is active, the 
resource is considered part of another domain. While the operator might have 
activated both the logical unit and the cross-domain resource representations of 
the same resource, only one of the definitions is used at a time. ACF/VTAM 
decides which definition to use by examining the state of the physical unit 
associated with the logical unit definition: 


e If the physical unit is unknown to ACF/VTAM (that is, the major node is 
not active, or the physical unit is not defined as owned by this ACF/VTAM 
and has not yet been acquired through the VARY ACQ command), the 
cross-domain resource definition is used. 


e If the physical unit is known but inactive, and if the CDRSC minor node is 
active, the cross-domain resource definition is used. 


e« If the physical unit is known but inactive, and if the CDRSC minor node is 
also inactive, the logical unit definition. is used. 


e If the physical unit is active, the logical unit definition is used. 


Resource Takeover Strategies 


e If the resource is an application program or a channel-attached non-SNA 
terminal, the ACF/VTAM physical unit (ISTPUS), which is always active 
as long as ACF/VTAM is running, is considered to be the resource’s 
physical unit. Therefore, as long as an application program or local 
non-SNA definition is known to ACF/VTAM (that is, as long as the major 
node is active), the application program or local non-SNA terminal 
definition is used. 


When a representation of a defined resource is not being used by ACF/VTAM, 
it is called a shadow resource. The representation currently being used is called 
the real resource. Operator commands cannot be entered for a shadow 
resource. Because real and shadow resources have the same name, all operator 
commands using that name are processed for the real resource. When the 
representation of a resource changes from a cross-domain resource to a logical 
unit, existing LU-to-LU sessions for the resource are switched (nondisruptively) 
to the logical unit representation, along with any I/O or buffer trace activity. 
The sessions become same-domain sessions. 


Figure 3-2 shows an example of the use of shadow resources. Suppose an 
application program named APPL 1 is in cross-domain session with a logical unit 
named LU2, and that a logical unit named LU1 is in cross-domain session with 
an application program named APPL2. If SSCP2 fails, SSCP1 can take over 
the resources of the NCP that were previously owned by SSCP2, including 
LU2. Because SSCP! already has an SSCP-to-NCP session with the NCP, the 
operator in SSCP1’s domain can enter VARY ACT (for example) for LU2’s 
physical unit (PU2), at which time the LU2 CDRSC becomes a shadow 
resource and the L.U2 LU becomes the real resource. No deactivation of the 
LU2 CDRSC is required. The cross-domain session between APPL1 and LU2 
becomes a same-domain session. (Note that the session becomes associated 
with LU2’s LU definition even though LU2 might not yet have been activated 
as an LU. LU2’s LU definition must be activated, however, before any new 
sessions can be started.) 


The session LU1 had with APPL2 was ended when HOST2, in which APPL2 
was running, failed. This application program can be started in HOST1 and a 
VARY ACT command can be entered to activate an application program major 
node containing an APPL definition for APPL2. At this point, the APPL2 
CDRSC becomes a shadow resource, and the APPL2 application program 
becomes the real resource. No deactivation of the APPL2 CDRSC is required. 
After APPL2 is active and running in HOST1, the session between APPL2 and 
LUI can be restarted. 


As previously described, the ability of an NCP to have multiple concurrent 
SSCP owners provides the option of automatic “lost control point” notification 
to the operators of the remaining SSCPs. Ownership of an NCP arises from the 
existence of an SSCP-to-NCP session, which in turn results froom a VARY ACT 


~or VARY ACQ command for the NCP. Only the SSCP-to-NCP session is 


needed for automatic notification about a lost SSCP, soa VARY ACT 
command specifying SCOPE=ONLY is sufficient. (That is, no miner nodes 
within the NCP need to be activated.) Alternatively, NCPs need not be shared, 
and operators can manually notify other (backup) operators when an SSCP fails. 
and takeover of an NCP is required. 
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Given these two methods of notification of the loss of an SSCP by an NCP and 
the potential need for resource takeover by another SSCP, ACF/VTAM 

provides three basic methods for resource takeover (the first two of which might 
normally be used with either type of notification): ; 


1. Sharing or taking over an NCP using the VARY ACT command (for a 
shared NCP, the NCP’s resources can be divided by operational procedures) 


2. Taking over a shared NCP using the VARY ACQ command (the NCP’s 
resources can be divided by assigning ownership to an SSCP within the 
NCP’s definition statements) 


3. Taking over an SDLC-link-attached NCP using the VARY ACQ command 
(takeover of an entire NCP, without division of resources) 


Those NCP resources that cannot be shared among more than one SSCP can be 
divided among the multiple owners of an NCP by operational procedures or by 
defining the division in the NCP definition. Resources that cannot be shared 
include physical units and logical units (and cross-subarea link stations in 
ACF/NCP/VS Release 2). Operational procedures can determine which SSCP 
should activate which resources. The first SSCP to request activation of a 
resource that cannot be shared becomes the (sole) owner; activation attempts of 
other SSCPs fail. Division of resources in the NCP definition involves the use 
of the BACKUP and OWNER operands in the resource definition statements. 
For more information, see ACF/VTAM Planning and Installation Reference. 


Method 3 can also be used (subject to the restrictions mentioned in the detailed 
discussion of this method below) in a manner similar to Method 1 Cincluding 
automatic “lost control point” notification). This might be done in order to use 
VARY ACOQ of individual physical units as well as VARY ACT to control the 
contention for resources among an NCP’s owners. 


These three methods are discussed in detail in separate sections below. General 
procedures applicable to all three methods are as follows: 


1. The domain operator at the backup SSCP must be notified of an 
SSCP-to-NCP session failure, either by the operator of the SSCP to be 
backed up, or by the automatic “lost control point” notification previously 
discussed. 


2. Upon being notified of an SSCP-to-NCP session failure, the operator at the 
backup SSCP starts any backup application programs and makes available 
any backup files that might have been available in the host system of the 
lost SSCP. 


3. The operator at the backup SSCP takes over the NCP Gif the NCP is not 
already active in the backup domain), and then takes over the resources 
formerly in the domain of the lost SSCP. 


4. As part of the takeover of the NCP’s physical units, they must be activated. 
Because activation of a physical unit that does not support the SNA request 
ACTPU(ERP) disrupts the LU-to-LU sessions of subordinate logical units, 
the operator should be aware of which physical units might have logical 
units with sessions that would be disrupted. 


For those logical units whose sessions would be disrupted, the backup 


SSCP’s operator might want to wait until all the sessions involving those 
logical units have terminated before activating the associated physical unit. 
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The existence of sessions with logical units can be determined by displaying, 
at this and other SSCPs, the status of the logical units or any application 
programs that might be in session with them. 


If the NCP being taken over had been dynamically reconfigured by the lost 
SSCP, the VARY DRDS command is used to reconfigure the NCP in the 
backup domain, using the appropriate dynamic reconfiguration files. 
Dynamically-added resources are then activated. 


The new domain ownership of the NCP’s logical units and of any backup 
application programs must be provided to other SSCPs in the network. The 
operator at the backup SSCP tells the operators at other locations that these 
resources are now part of the backup SSCP’s domain. These operators 
enter the appropriate command to inform their SSCPs of the new (backup) 
SSCP now responsible for the resources of the lost SSCP. In ACF/VTAM, 
the MODIFY CDRM command is used. Existing cross-domain sessions are 
unaffected by this command. ; 

MODIFY CDRM might not be necessary to change the CDRM ownership 
of dynamically-defined CDRSCs. See “Changing CDRMs for 
Cross-Domain Resources’’in Chapter 2 for details. 


After the lost SSCP has been recovered, the domain operators at the 
backup SSCP and the recovered SSCP must cooperate to return the NCP’s 
resources to their original owner. Unless a “nondisruptive return” 
procedure can be used, the process of returning these resources disrupts all 
of their existing sessions because the physical units must be deactivated in 
order to return them. (See “Nondisruptive Return of NCP Resources” for 
details of configurations and procedures for the nondisruptive return of an 
NCP’s resources. ) 


The operator at the recovered SSCP can also avoid disrupting existing 
sessions by allowing the NCP resourcés to remain under the control of the 
backup SSCP, using the NCP’s logical units as cross-domain resources. 

This permits the recovered SSCP’s application programs to have sessions 
with these logical units until a convenient time is found to return the NCP’s 
resources. | 


The activation of an NCP’s physical units by the recovering SSCP wili fail if 
they are still owned by the backup SSCP. If the backup SSCP has not yet 
deactivated an NCP’s physical units, the operator at the recovering SSCP 
might want to ensure that these physical units are not automatically 
activated when ACF/VTAM is restarted and the NCP is reactivated. This 
can be done by not using a CONFIG list that will activate the NCPs 
containing the physical units, and by specifying SCOPE=ONLY on the 
VARY ACT command for each NCP. After the physical units have been 
deactivated by the backup SSCP, the recovering SSCP can resume 
ownership by activating them. 


With the restoration of resource ownership to the recovered SSCP, other 
SSCPs in the network must again be notified of the change in ownership of 
the NCP’s logical units and any (formerly backed-up) application programs. 
The operator at the recovered SSCP tells the operators at other locations 
that these resources are now back in the original SSCP’s domain. These 
operators enter the appropriate command to inform their SSCPs of the new 
(recovered) SSCP now responsible for the resources. In ACF/VTAM, the 
MODIFY CDRM command is used. 


MODIFY CDRM might not be necessary to change the CDRM ownership 
of dynamically-defined CDRSCs. See “Changing CDRMs for 
Cross-Domain Resources”in Chapter 2 for details. 


Migration Considerations: See the migration considerations described under 
“SSCP-to-NCP Session Failure.” 


Resource Takeover in an NCP Using the VARY ACT Command 


The ACF/VTAM operator can share or take over an NCP and take over the 
NCP’s resources using the VARY ACT command. 


1, 


To become a shared owner of an NCP in preparation for a backup role in 
the NCP’s operation, or after receiving notification that an NCP has lost an 
SSCP in another domain (if the NCP is not being shared), the operator 
enters: 


VARY NET,ACT,ID=ncp name,SCOPE=ONLY 


If the NCP is being activated to prepare the SSCP for the role of a standby 
owner for backup, the SCOPE=ONLY operand achieves this NCP 
ownership without activating the NCP’s minor nodes. If the SSCP is to 
control some of the NCP’s resources during normal operations (that is, if 
the NCP’s resources are to be divided by operational procedures), the 
resources to be controlled by the operator entering this command might be 
activated individually. 


if the NCP is being activated after the operator has been notified that the 
NCP has lost an SSCP in another domain, the SCOPE=ONLY operand 
ensures that nore of the NCP’s physical units or logical units are activated, 
thereby avoiding the possible disruption of existing sessions with the logical 
units (if their physical units do not support the ACTPU(ERP) request). 


All of the NCP’s resources may be activated at once in the backup host if 
the session disruption possibilities do not apply or do not matter to the 
installation. To activate all of the NCP’s resources, the operator enters: 


VARY NET,ACT,ID=ncp name,sSCOPE=ALL 


This command can be entered even if the NCP is already active. 
SCOPE=U can be specified instead of SCOPE=ALL to activate the NCP’s 
resources to their defined initial status. 


If possible session disruption is a consideration, the operator can proceed 
with the takeover as described in the remaining steps below. 

For any resources other than physical units and logical units (such as lines 
and link stations), the operator enters: 


VARY NET,ACT,[D=resource name 


The considerations for the SCOPE operand on the activation of these 
resources are. the same as for the SCOPE operand on the activation of the 
NCP itself. The operator must decide whether a line, for example, that has 
subordinate physical and logical units with active sessions should be 
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Returning the NCP’s Resources After Recovery: 


activated with SCOPE=ONLY to protect the sessions. (The default value, 
SCOPE=COMP, has the same effect as SCOPE=ONLY for line minor 


nodes.) 


Each physical unit is activated by entering: 
VARY NET,ACT,ID=physical unit name 


This command will disrupt existing sessions with the physical unit’s logical 
units if the physical unit does not support the ACTPU(CERP) request. 


The logical units can be activated using the SCOPE operand, or they can be 
activated individually. These activations will disrupt existing sessions of the 


Jogical units if the logical units do not support the ACTLU(CERP) request. 


The following actions allow the 


original SSCP to regain its resources: 


1. 


The operator of the recovering SSCP enters: 
VARY NET,ACT,ID=ncp name,SCOPE=ONLY 


to reestablish the SSCP-to-NCP session. 


To give up ownership of each resource that has been taken over, the backup 
SSCP’s operator enters: 


VARY NET,INACT,[D=resource name 


Recall that if the resource is a logical unit or one of its superior resources 
(that is,.the physical unit or line), the logical unit’s LU-to-LU sessions must 
be ended for the deactivation to complete. A stronger form of VARY 
INACT can be used if necessary. 


Note that giving up a logical unit in the backup SSCP does not make it 
available to the recovering SSCP unless the physical unit is also given up. 


The operator of the recovering SSCP takes back each of its resources by 
entering: 


VARY NET,ACT,ID=resource name 


Alternatively, the SSCP’s resources can be taken back by using a single 
VARY ACT command for the NCP (even if the NCP has been activated 
already), specifying an appropriate value of the SCOPE operand. 


After all of the NCP’s resources have been taken back by the recovering 
SSCP, the operator of the backup SSCP can give up ownership of the NCP 
itself Gif the SSCP is not to continue to maintain standby owncrship for — 
future backup procedures). The operator enters: 


VARY NET, INACT,ID=ncp name,CDLINK=ACT 


The CDLINK operand is optional but might be necessary to prevent 
disruption of sessions on cross-domain links. Refer to ‘“Deactivating an 
NCP” in Chapter 2 for a full discussion of this and other possible disruptive 
effects of NCP deactivation. 


Resource Takeover in a Shared NCP Using the VARY ACQ Command 


The resources of an NCP can be explicitly divided for sharing among two or 
more SSCPs by using the OWNER operand on the applicable resource 
definition statements. In addition, the BACKUP=YES specification in the NCP 
definition allows a backup SSCP to take over the resources it does not normally 

, own. Thus, for example, two SSCPs might each own half of an NCP’s 
resources (each operator having entered VARY ACT), with each backing up the 
other’s half. When one SSCP fails, the other takes over ail of the resources it 
does not normally own when the operator of the backup SSCP enters a VARY 
ACQ command for the NCP. Another example is where one SSCP is defined 
as the owner of all of the NCP’s resources, such that VARY ACT in the other 
(backup) SSCP merely establishes the SSCP-to-NCP session (for purposes of 
automatic “lost control point” notification). When the principal SSCP fails, the 
operator of the backup SSCP enters VARY ACQ, and in this example, takes 
over all of the NCP’s resources (because none were defined with the backup 
SSCP as the normal owner). 


Note that, as described below, this method of takeover requires individual 
VARY ACQ commands for each physical unit after entering VARY ACQ for 
the NCP as a whole. This extra step replaces the judicious use of the 
SCOPE=ONLY specification on VARY ACT as described in the first method 
of NCP takeover above, in order to avoid potential session disruption during 
takeover. 


The ACF/VTAM operator takes over a shared NCP’s resources using the 
following procedure. 


1. After receiving notification that a shared NCP has lost an SSCP in another 
domain, the operator enters: 


VARY NET,ACQ,ID=ncp name 


The NCP’s resources (except physical units and logical units) can be 
activated using the ACT and SCOPE operands, or they can be activated 
individually. 


2. Each physical unit is taken over by entering: 
VARY NET,ACQ,ID=physical unit name 


The physical unit can be activated using the ACT operand, or it can be 
activated separately. As with the VARY ACT command for a physical unit, 
the ACT operand used with VARY ACQ of a physical unit disrupts existing 
sessions with the physical unit’s logical units if the physical unit does not 
support the ACTPU(ERP) request. 


The logical units can be activated using the SCOPE operand, or they can be 


activated individually. These activations disrupt existing sessions of the 
logical units if the logical units do net support the ACTLU(ERP) request. 
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Returning the NCP’s Resources After Recovery: The following actions allow the 
original SSCP to regain its resources: 


1. The operator of the recovering SSCP enters: 


VARY NET,ACT,[ID=ncp name,sSCOPE=ONLY 


to reestablish the SSCP-to-NCP session. 


The backup SSCP’s operator can use a single command to give up 
ownership of all of the resources that were taken over, cr can give up 
ownership of each physical unit individually. To give up each physical unit 
individually, the operator enters: 


VARY NET,REL,ID=physical unit name 


As with VARY INACT, the LU-to-LU sessions of the physical unit’s logical 
units must be ended for the release to complete. A stronger form of VARY 
REL can be used if necessary. 


To give up ownership of the remaining resources that were taken over, or to 
give up ownership of all such resources if individual VARY REL commands 
were not used in the preceding step, the backup SSCP’s operator enters: 


VARY NET,REL,[D=ncp name,CDLINK=ACT 


This VARY REL command does not affect any physical units that originally 
belonged to the backup SSCP. 


If CDLINK=ACT is not specified, any cross-domain links that were taken 
over are deactivated, and any sessions using the links are disrupted (unless 
the links and link stations have been activated by other SSCPs). 


The operator of the recovering SSCP takes back each of its resources by 
entering: 


VARY NET,ACT,ID=resource name 


Alternatively, the SSCP’s resources can be taken back by using a single 
VARY ACT command for the NCP (even if the NCP has been activated 
already), specifying an appropriate value of the SCOPE operand. 


Resource Takeover in an SDLC-Link-Attached NCP Using the VARY ACQ 


Command 
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The ACF/VTAM operator can take over an inactive NCP attached through an 
active SDLC link station in an adjacent node by using the VARY ACQ 
command. | 


. After receiving notification that an NCP has lost an SSCP in another 


domain, and if an active SDLC link connection is not already available in 
the backup SSCP, the ACF/VTAM operator at the backup SSCP enters: 


VARY NET,ACT,[ID=link station name 


where the link station name is the name of a link station associated with an 
SDLC link leading to the NCP that is to be taken over. 


2. The ACF/VTAM operator at the backup SSCP takes over the NCP by 
entering: 


VARY NET,ACQ,ID=ncp name 


The NCP’s resources (except physical units and logical units) can be 
activated using the ACT and SCOPE operands, or they can be activated 
individually. 


3. Each physical unit is taken over by entering: 
VARY NET,ACQ,ID=physical unit name 


The physical unit can be activated using the ACT operand, or it can be 
activated separately. As with the VARY ACT command for a physical unit, 
the ACT operand used with VARY ACQ of a physical unit disrupts existing 
sessions with the physical unit’s logical units if the physical unit does not 
support the ACTPU(ERP) request. 


The logical units can be activated using the SCOPE operand, or they can he 
activated individually. These activations disrupt existing sessions of the 
logical units if the logical units do not support the ACITLUCERP) request. 


Returning the NCP’s Resources After Recovery: The following actions allow the 
origina! SSCP to regain its resources: 


1. The operator of the recovering SSCP enters: 
VARY NET,ACT,[D=ncp name, SCOPE=ONLY 


to reestablish the SSCP-to-NCP session. 


2. The backup SSCP’s operator can use a single command to give up 
ownership of the entire NCP. or can give up ownership of each physical 
unit individually. ‘To give up each physical unit individually, the operator 
enters: , : 


VARY NET,REL,ID=physical unit name 


As with VARY INACT, the LU-to-LU sessions of the physical unit’s logical 
units must be ended for the release to complete. A stronger form of VARY 
REL can be used if necessary. 


3. To give up ownership of the remaining resources and the NCP itself, the 
backup SSCP’s operator enters: 


VARY NET,REL,ID=ncp name,CDLINK =ACT 
If CDLINK=ACT is not specified, active cross-domain links are 


deactivated, and any sessions using the links are disrupted (unless the links 
and link stations are shared by other SSCPs). 
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4, The operator of the recovering SSCP takes back each of its resources by 
entering: 


VARY NET,ACT.JD=resource name 
Alternatively, the SSCP’s resources can be taken back by using a single 


VARY ACT command for the NCP (even if the NCP has been activated 
already), specifying an appropriate value of the SCOPE operand. 


Nondisruptive Return of NCP Resources 


89 


Although, in general, the return of NCP resources to an original owner is 
disruptive, there are certain network configurations and procedures that make it 
possible for a backup SSCP to return NCP resources to their original owner 
without disrupting LU-to-LU sessions. Consider the configuration shown in 
Figure 3-3. In this example, HOST1 is dedicated to network management; that 
is, control of network resources is centralized in HOST1, and all application 
programs are in other host processors. (This is known as a communication 
management configuration, or CMC.) Suppose that HOST1 fails and that 
another host, named HOST1B, is to be used for backup. HOST1B performs 
resource takeover using the VARY ACT command as described in “Resource 
Takeover Strategies” and “Resource Takeover in an NCP Using the VARY 
ACT command.” After HOST1 recovers, HOST1B must be withdrawn from 
the network to allow HOST1 to take back control of the network resources. 


This can be done by having the domain operator at HOST1B deactivate the 
channel link OD1-L. This deactivation breaks all routes between HOST1B and 
the rest of the network, causing all of the NCPs controlled by HOST1B to go 
through the NCP’s automatic network shutdown procedure with respect to 
HOSTIB. As with the original failure of HOST1, only those sessions that 
cannot survive the automatic network shutdown procedure are disrupted. 
HOST1 can then re-enter the network by performing a resource takeover from 
HOST1B, just as HOST1B did when HOST1 failed. Only LU-to-LU sessions 
with logical units that do not support the ACTLU(ERP) request, or with logical 
units subordinate to physical units that do not support the ACTPU(ERP) 
request, are disrupted. 


The requirements for nondisruptive return of NCP resources (that is, in addition 
to those for nondisruptive takeover) can be summarized as follows: 


e All channel links connecting the backup host to the network must be 
deactivated when the return of NCP resources is desired. 


e The backup host must contain no application programs, so that it can be 
removed from the network without removing participants in LU-to-LU 
sessions. 


If application programs are allowed to run in HOST1, and are moved into 
HOST1B when HOST! fails, there must be further disruption of these 
application programs if the above method is used to return NCP resources to 
HOST1. However, the disruption will be limited to those application programs 
in HOST1B, as they are moved back into HOST1. 
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Figure 3-3. Nondisruptive Return of NCP Resources 
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Chapter 4. ACF/VTAM Operator Commands 


This chapter is a reference section on the ACF/VTAM operator command 
facilities. It includes a description of the format and the applicable operands for 
each command. The descriptions are arranged alphabetically by command. 
Whenever it is appropriate, a table is given of the node types for which the 
command can be used. For each operand, a bullet appears in the columns of all 
node types for which the operand can be used. : 


Command Fundamentals 


An ACF/VTAM operator command consists of the command name or its 
abbreviation and various operands that describe the operation to be performed. 
Each ACF/VTAM operator command has a procedure name that tells the 
operating system that the command is to be sent to ACF/VTAM for 
processing. The procedure name must be the first operand entered on a 
command. The procedure name varies according to what command is used and 
on the operating system. 


In OS/VS2 systems, the procedure name for ACF/VTAM commands is NET, 
with the exception of the MODIFY command, which uses the name of the 
ACF/VTAM start procedure for the procedure name. For consistency and ease 
of operation, it is recommended that the ACF/VTAM start procedure be named 
NET. 


In OS/VS1 systems, the procedure name for ACF/VTAM commands is NET, 
with the exception of the MODIFY command. For the MODIFY command, the 
procedure name must be in the form procname .Pnn, where procname is the name 
of the procedure that was used to start ACF/VTAM and na is a 1- or 2-digit 
decimal number that indicates the partition in which ACF/VTAM is running. 

For example if the name of the start procedure is NET, and ACF/VTAM is 
running in partition number 2, then the procedure name for the MODIFY 
command is “NET.P0O2.” For consistency and ease of operation, it is 
recommended that the ACF/VTAM start procedure be named NET. 


In VSE systems, the procedure name for ACF/VIFAM commands is always 
NET. 


To avoid needless repetition, the NET operand is not described in every 


command description. However, on MODIFY commands where the procedure 
name is different for each operating system, each possibility is described. 


Syntax Notation 
Throughout this publication the formats of ACF/VTAM operator commands 


use the syntax notation described below. The following VARY REL command 
syntax is used as an example. 
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Operation — Operands 


fVARY|V}—s NET. RELJD=name > 
| | [,CDLINK=ACT | INACT] 


Uppercase Characters 


Command names or operands consisting of uppercase characters must be spelled 
as shown but can be entered in uppercase or lowercase. In the example, the 
REL operand is shown in uppercase characters because it must be entered 
exactly as shown. 


Lowercase Characters 


Lowercase characters are variables that show the kind of information, rather 
than the exact information, that must be supplied. The actual entry, usually the 
name of a resource, replaces the lowercase description. In the example, the © 
‘‘name” part of the ID operand is shown in lowercase characters because it must 
be replaced with the name of an NCP or a physical unit. | 


Underscored Values 


An underscored value indicates the default value that is assumed for an operand 
if that operand is not specified in the command. In the example, the 
underscoring of INACT indicates that CDLINK=INACT is the default value 
for the CDLINK operand. 


Braces { } 

Braces are used to indicate the available options for a required specification. 
For example, there are two ways to specify the VARY command. Either the 
full command name (VARY) or its abbreviation (V) can be specified, but one 
of them must be specified. 

Braces are never included when entering the desired option. 

Square Brackets [ ] 

When square brackets enclose an operand, they indicate a completely optional 
specification. This includes any accompanying commas or equal signs. For 
example, the CDLINK and I operands are optional on the VARY REL 


command. 


Square brackets are not included when entering the specification. 


Or-sign | 


The or-sign is used to separate options for a single optional or required 
specification. If a group of options is enclosed by square brackets, and the 
individual options are separated by or-signs, none of the options in the group 
has to be chosen. If none of these operands are coded, the default value is 
used. Default values are always underscored. 


In the example, The or-sign in CDLINK=ACT | INACT in the syntax 
description indicates that either CDLINK=ACT or CDLINK=INACT can be 
specified for the CDLINK operand. The or-sign should not be included as part 
of the command. 


Commas and Equal Signs 


Commas and equal signs must be entered as shown. When commas and equal 
signs appear within brackets, they are optional and are to be used only if the 
accompanying optional operand is used. 


Entering Operator Commands 


Operator commands are entered and ACF/VTAM messages are received at the 
system console or remote network console. Details of the formats of all the 
ACF/VTAM operator commands can be found later in this chapter. 


Operator command input devices, particular program operator application 
programs (such as the Network Communications Control Facility [NCCF]), and 
the ACF/VTAM program operator interface impose size limitations on the 
length of ACF/VTAM operator commands that can be entered. Except for the 
prompting that ACF/VTAM provides for start options, all ACF/ VTAM 
operator commands must be entered on a single input line from whatever input 
device is being used. 


Valid and Invalid Commands 


ACF/VTAM issues messages that tell the operators whether the commands 
they entered were accepted or rejected. Note that this does not indicate 
command completion. When a command is entered correctly, with valid 
operands, ACF/VTAM issues a message of acknowledgment. If an error is 
made in entering a command, ACF /VTAM issues one or more error messages 
and rejects the command. 


System-Programmer-Modified Command Syntax 


The system programmer can supply a modified syntax for an ACF/VTAM 
command if that command is defined in the IBM-supplied USS definition table 
ISTINCNO. If the syntax of a command has been changed, it is the 
responsibility of the system programmer to supply the operator with an 
explanation of the new command syntax. For more information , see 
ACF/VTAM. Planning and Installation Reference. 
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DISPLAY APPLS Command 


To display the status of all active application program major nodes in the 
domain and their respective application program minor nodes, enter: 


Operation Operands 


{DISPLAY | D} NET,APPLS 
[,ACT | EVERY | INACT] 


ACT | EVERY | INACT : 
specifies the desired scope of the display. 


ACF/VTAM treats resources in transition to or from the active state as 
“active” for the purposes of the display; otherwise the resources are 
considered to be “‘inactive.” 


ACT | 
specifies that the names of all active application program minor nodes 
within each major node are to be displayed. 


ACT may be abbreviated as A. 


EVERY 
specifies that the name and status of all application program minor 
nodes within each major node are to be displayed (regardless of their 
status). 


EVERY is the default value; it may be abbreviated as E. 


INACT 
specifies that the names of all inactive application program minor nodes 
within each major node are to be displayed. 


INACT may be abbreviated as I. 


The resulting ACF/VTAM display indicates: 


¢ The name and status of each active application program major node. 
Inactive application program major nodes are not known to ACF/VTAM 
and are therefore not displayed. 


¢ For each active application program major node, the name and status of 
each subordinate application program minor node (limited to active or 
inactive minor nodes if so requested in the DISPLAY command). 
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DISPLAY BFRUSE 


DISPLAY BFRUSE Command 


To display information about ACF/VTAM buffer use, enter: 


Operation Operands 


{DISPLAY | D} NET,BFRUSE 


The resulting display indicates for each ACF/VTAM buffer pool: 


e The buffer pool identification. 


«The existence of queued buffer requests (indicated by a Q after the buffer 
pool identification). 


e Whether an expansion attempt has failed (indicated by an F after the buffer 
pool identification). 


e« The size (in bytes) of each buffer. (Note that for certain buffer pools, such 
as IOBUF in OS/VS and LFBUF in VSE, the size displayed might not 
match the size specified in the buffer pool start options. This occurs 
because ACF/VTAM increases the size of some buffers to allow for buffer 
headers that must be added to those buffers.) 


« The number of buffers currently assigned to the pool. 
¢ The number of buffers currently available for use. 


e The maximum number of buffers ever assigned to the pool (since the last 
SMS trace record was written, if an SMS trace is active). 


¢ The maximum number of buffers ever used within the pool (since the last 
SMS trace record was written, if an SMS trace is active). 


e The number of times that the buffer pool has been expanded (since the last 
SMS trace record was written, if an SMS trace is active). 


¢ The number of available buffers at or below which expansion is to occur. 
This field contains “N/A” (not applicable) if the dynamic buffer expansion 
function is not being used. 


e The number of available buffers at or above which contraction is to be 
attempted. This field contains “N/A” (not ancerey if the dynamic 
buffer expansion function is not being used. 


e The number of buffers to be added during each expansion. This field 
contains “N/A” (not applicable) if the dynamic buffer expansion function 
is not being used. 


Note for OS/VS2 (MVS) Systems Only: ~ACF/VTAM’s common service area 
(CSA) usage limit, current usage, and maximum usage are also provided in this 
display. 
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Note for VSE Systems Only: Some of the values that are normally displayed as 
a number of buffers are instead displayed as a number of pages for certain 

buffer pools. In these cases, the number is suffixed by a P. Also, for the 
variable-length fixed pool (VFBUF) and the variable-length pageable pool 
(VPBUF), dynamic buffer expansion does not apply; therefore, information 
applicable only to the expansion function is displayed as “N/A” (not 

applicable). 


For more information about using ACF/VTAM buffer use data, see the 
ACF/VTAM Diagnosis Guide. 


DISPLAY CDRMS 


DISPLAY CDRMS Command 


To display the status of all active cross-domain resource manager (CDRM) 
major nodes in your domain of a multiple-domain network, enter: 


Operation Operands 


{DISPLAY | D} NET,CDRMS 
[ACT | EVERY | INACT] 


ACT | EVERY | INACT 
specifies the desired scope of the display. 


ACF/VTAM treats resources in transition to or from the active state as 
‘active’ for the purposes of the display; otherwise the resources are 
considered to be ‘“‘inactive.”’ 


ACT 
specifies that information is to be displayed about all active CDRM 
minor nodes within each major node. 


ACT may be abbreviated as A. 
EVERY 


specifies that information is to be displayed about ail CDRM minor 
nodes within each major node (regardless of their status). 


EVERY is the default value; it may be abbreviated as E. 


INACT 
specifies that information is to be displayed about all inactive CDRM 
minor nodes within each major node. 


INACT may be abbreviated as I. 


The resulting display indicates: 


e The name and status of each active CDRM major node. 


¢« For each active CDRM major node, the name, status, and subarea address 
of each subordinate CDRM minor node (limited to active or inactive minor 
nodes if so requested in the DISPLAY command). 


Inactive CDRM major nodes are not known to ACF/VTAM and arc therefore 
not displayed. 
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DISPLAY CDRSCS Command 


To display information about all active cross-domain resource (CDESC) paalor. 
nodes in your domain of a multiple-domain network, enter: | 


Operation ncuans 


{DISPLAY | D} NET,CDRSCS 
[.ACT | EVERY | INACT] 


ACT | EVERY | INACT 
specifies the desired scope of the display. 


ACF/VTAM treats resources in transition to or from the active state as 
“active” for the purposes of the display; otherwise the resources are 
considered to be “inactive.” 


ACT 
specifies that information is to be displayed about all active CDRSC 
minor nodes within each major node. 


ACT may be abbreviated as A. 


EVERY 
specifies that information is to be displayed about all CDRSC minor 
nodes within each major node (regardless of their status). 


EVERY is the default value; it may be abbreviated as E. 


INACT 
specifies that information is to be displayed about all inactive CDRSC 
minor nodes within each major node. 


INACT may be abbreviated as I. 


The resulting display indicates: 


« The name and status of each active CDRSC major node in the domain. 
Inactive CDRSC major nodes are not known to ACF/VTAM and are 
therefore not displayed. 


e For each CDRSC major node, the name, status, and owning CDRM of each 
subordinate CDRSC minor node (limited to active or inactive minor nodes 
if so requested in the DISPLAY command). 


DISPLAY CLSTRS 


DISPLAY CLSTRS Command 


To display the status of all physical units, and their respective major nodes, 
enter: | 


Operation Operands 


{DISPLAY | D} NET,CLSTRS 
[,ACT | EVERY | INACT] 


ACT | EVERY | INACT 
specifies the desired scope of the display. 


ACF/VTAM treats resources in transition to or from the active state as 
“active” for the purposes of the display; otherwise the resources are 
considered to be “‘inactive.”’ 


ACT 
specifies that information is to be displayed about all active physical 
units within each major node, and their respective major nodes. 


ACT may be abbreviated as A. 


EVERY 
specifies that information is to be displayed about all physical units 
within each major node (regardless of their status), and their respective 
major nodes. 


EVERY is the default value; it may be abbreviated as E. 


INACT 
specifies that information is to be displayed about all inactive physical 
units in the domain, and their respective major nodes. 


INACT may be abbreviated as I. 


The resulting ACF/VTAM display indicates: 


e For each active major node defining physical units, the major node name 
and type, the names of the active physical units, inactive physical units, or 
every physical unit (as specified in the DISPLAY command) associated with 
the major node, and the status and node type for each subordinate resource 
listed. 


e For local SNA major nodes, the channel device name for every physical unit 
in the local SNA major node. 
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The DISPLAY ID command provides information about a particular major node 
or minor node. Optionally, additional information can be displayed about the 
node’s subordinate resources. 


To display the status of an active major node or of a minor node within an 
active major node, enter: 


Operation Operands 


{DISPLAY|D} NET,ID=name 
[ACT | EVERY | INACT | NONE] 


[ID=name | 
specifies the name of a major node or minor node. 


Notes: 


|. This command does not apply to application program major nodes. 


2. For an application program in this domain, the ID operand can specify 
either the application program minor node name or the name under 
which the application program opened its ACB. 


3. In general, this command applies only to active major nodes and minor 
nodes within active major nodes. Inactive subarea nodes (for example, 
NCP major nodes) that have been contacted by ACF/VTAM as a result 
of the activation of a cross-subarea link station can be displayed, if the 
name is known to ACF/VTAM. This is the case only when both the 
NCP being displayed and the NCP containing the link station are 
ACF/NCP/VS Release 3. With this one exception, inactive major 
nodes and their minor nodes are not known to ACF/VTAM and are 
therefore not displayed. 


ACT | EVERY | INACT | NONE 
specifies the desired scope of the display. 


The ACT, EVERY, INACT, and NONE operands specify whether 
information is to be provided about the specified node’s subordinate 
resources in addition to the information about the node itself. These 
operands have meaning only for resources that have subordinate resources. 
Depending on the type of resource specified with the ID operand, different 
subordinate resources can be displayed as result of the ACT, EVERY, or 
INACT operand. The different types of subordinate resources that are 
displayed for each major node or minor node are listed later in this 
discription. 


ACEF/VTAM treats resources in transition to or from the active state as 
“active” for the purposes of the display; otherwise the resources are 
considered to be “‘inactive.”’ 


DISPLAY ID 


ACT 
specifies that, in addition to the name and status of the resource 
specified on the ID operand, the name and status of all its active 
subordinate resources, if any, are to be displayed. 


ACT may be abbreviated as A. 


EVERY 
specifies that, in addition to the name and status of the resource 
specified on the ID operand, the name and status of all its subordinate 
resources, if any, are to be displayed (regardless of their status). 


EVERY may be abbreviated as E. 


INACT 
specifies that, in addition to the name and status of the resource 
specified on the ID operand, the name and status of all its inactive 
subordinate resources, if any, are to be displayed. - 
INACT may be abbreviated as I. 


NONE 
tells ACF/VTAM not to display the name and status of any 
subordinate resources. 


NONE is the default value; it may be abbreviated as N. 


The resulting display shows the name and status of the resource specified on the 
ID operand. In addition, if the ACT, EVERY, or INACT operand is specified, 
the display shows information about the node’s subordinate resources. ‘The 
following list shows the subordinate resources whose name and status are 
displayed for each major node and minor node. This display can be limited to 
active or inactive resources, or all resources can be displayed, depending on 
whether the ACT, INACT, or EVERY operand is specified. 


e Major Nodes: 


—- For ID=CDRM major node, its subordinate CDRMs. 
—- For ID=CDRSC major node, its subordinate CDRSCs. 


- For ID=local SNA major node, its subordinate logical units and the 
physical units to which the logical units are subordinate. 


- For {D=local non-SNA 3270 major node, its subordinate logical units. 
— For ID=NCP major node, its subordinate lines. 
— For ID=ISTPUS, its subordinate cross-subarea links. 


- For ID=switched major node, its subordinate logical units and the 
physical units to which the logical units are subordinate. 
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DISPLAY ID 


Minor Nodes: 


For ID=application program minor node or ACB name: 


— For ACT, the established sessions with the application program. 


— For INACT, the names of logical units waiting for sessions with the 
application program. 


— For EVERY, the information provided for both ACT and INACT, 
as described above. 


For ID=CDRSC minor node: 


— For ACT, the established sessions with the cross-domain resource. 


— For INACT, the names of logical units waiting for sessions with the 
cross-domain resource. 


— For EVERY, the information provided for both ACT and INACT, 
as described above. 


For [D=external CDRM name, only the cross-domain resources with 
established sessions that are owned by the external CDRM. 


For ID=host CDRM name, only the external CDRM session partner 
and session status for established sessions with the host CDRM. 


For [D=line, either: 


— Its subordinate link stations. 


—- Its subordinate logical units and the physical units to which the 
logical units are subordinate. 


For [D=physical unit, its subordinate logical units. 


DISPLAY LINES 


DISPLAY LINES Command 


To display the status of the lines in the domain, enter: 


Operation Operands 


{DISPLAY | D} NET,LINES 
[ACT | EVERY | INACT] 


ACT | EVERY | INACT 
specifies the desired scope of the display. 


ACF/VTAM treats resources in transition to or from the active state as 
‘active’ for the purposes of the display; otherwise the resources are 
considered to be ‘“‘inactive.”’ 


ACT 
specifies that information is to be displayed about all active lines within 
each major node, and their respective major nodes. 


ACT may be abbreviated as A. 


EVERY 
specifies that information is to be displayed about all lines within each 
major node (regardless of their status), and their respective major 
nodes. 


EVERY is the default value; it may be abbreviated as E. 


INACT 
specifies that information is to be displayed about all inactive lines 
within each major node, and their respective major nodes. 


INACT may be abbreviated as I. 


For each active major node containing lines, the resulting ACF/VTAM display 
indicates the name and status of each line within the major node (limited to 
active or inactive minor nodes if so requested in the DISPLAY command). 
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To display the status of all the active major nodes in the domain, enter: | 


Operation _ Operands 


{DISPLAY|D} NET,MAJNODES 


This command displays the status of all active major nodes, which includes the 
following major node types: 


_e Application program 


« CDRM (in a multiple-domain network) 

¢ CDRSC (in a multiple-domain network) 

e Local SNA 

« Local non-SNA 3270 

« NCP (see note below) 

e Switched 

Note: NCP major nodes, which are type 4 physical units, are listed in the 
display as PU__T4/5 major nodes. The ACF/VTAM physical unit, ISTPUS, 


which is a type 5 physical unit, is also listed in the display as a PU__T4/5 
major node. 


The resulting display indicates the name, type, and status of each known major 
node. 


DISPLAY NCPSTOR 


DISPLAY NCPSTOR Command 


The storage contents of a communication controller running an NCP can be 
dynamically displayed at the ACF/VTAM operator’s console. Up to 256 
(decimal) bytes from any address within the communication controller can be 
dynamically displayed with each DISPLAY NCPSTOR command. To display 
NCP storage, enter: 


Operation Operands 


{DISPLAY|D} | NET,NCPSTOR,[D=ncpname,ADDR=address 
|LLENGTH=n | 32] 


NCPSTOR 
is a positional parameter and must appear immediately after NET. 


ID=ncpname 
specifies the name of the NCP whose storage is to be displayed. 


ADDR =address 
specifies the address (in decimal) of the first byte of data to be displayed. 


LENGTH=nh | 32 | 
specifies the number of bytes of NCP storage to be displayed. Any decimal 
integer in the range 1 through 256 can be specified. If no value is 
specified, ACF/VTAM displays 32 bytes. 
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DISPLAY PATHS Command 


To display dial-out path information about a switched physical unit, enter: 


Operation Operands | 


{DISPLAY | D} | NET.PATHS, ID =switched physical unit name 


ID=switched physical unit name 
specifies the name of a switched physical unit. 


Note: The PATHS operand may be abbreviated as P. 
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DISPLAY PATHTAB 


DISPLAY PATHTAB Command 


The DISPLAY PATHTAB command provides essentially the same information 
as the DISPLAY ROUTE command, but does so in a different format. It is 
provided primarily for continuity with previous releases of ACF/VTAM 
(although the format and contents of the output differs from that of previous 
releases). The command can be used to display information about all routes, or 

may be limited by specifying the ADJSUB or DESTSUB operands. To display 
the status of explicit routes and their associated virtual routes, enter: 


Operation Operands 


{DISPLAY | D} NET,PATHTAB 
[f ADJSUB=subarea | DESTSUB=subarea| 


PATHTAB : 
iS a positional parameter and must appear immediately after NET. 


ADJSUB=subarea 
specifies that only information relating to routes passing through the named 
adjacent subarea is to be displayed. 


DESTSUB=subarea 
specifies that only information relating to routes going to the named 
destination subarea is to be displayed. 
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To display information about those nodes in the domain in a “pending” state 
(that is, in a transient state to or from the fully active state, or with a BIND or 
UNBIND outstanding), enter: 


Operation Operands 


{DISPLAY | D} NET,PENDING 


The resulting ACF/VTAM display indicates the name and status of each 
network node in a “pending”’ state. 


DISPLAY ROUTE 


DISPLAY ROUTE Command 


To display the status of explicit routes and virtual routes in the domain, enter: 


Operation Operands 


{DISPLAY | D} NET,ROUTE,DESTSUB=subarea 
[,COSNAME=name | ER=n|ER=ALL | VR=n] 
[,TEST=YES | NO] 


ROUTE 
is a positional parameter and must appear immediately after NET. 


DESTSUB =subarea 
specifies the subarea address of the destination subarea of the routes to be 
displayed. The origin subarea for the routes to be displayed is always the 
subarea of the ACF/VTAM host processor to which the DISPLAY ROUTE 
command is issued. 


COSNAME=name | ER=n| ER=ALL| VR=n 
specifies which explicit routes or virtual routes are to be displayed. 


COSNAME=name 
specifies a class of service name. If this operand is specified, all virtual 
routes to the specified destination subarea within this class of service 
are displayed. 


If COSNAME is specified, neither the VR nor the ER operands may be 
specified. 


ER=n 
specifies the explicit route number (an integer from O through 7). If 
this operand is specified, all the explicit routes identified by this explicit 
route number that are known to ACF/VTAM to the specified 
destination subarea are displayed. An explicit route becomes known to 
ACF/VTAM either by having been defined at one time (through the 
activation of a path definition set defining the ER), or by having been 
operative at one time (through the receipt of an ER__ OP request unit 
from the network). 


If ER is specified, neither the COSNAME nor the VR operands may be 
specified. 


ER=ALL 


specifies that every explicit route to the specified destination subarea is 
to be displayed. 


If ER is specified, neither the COSNAME nor the VR operands may be 
specified. 


If none of the COSNAME, ER, or VR options are specified, ER=AI.L. 
is assumed. 
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VR=n 


specifies the virtual route number (an integer from 0 through 7). If this 
operand is specified, the virtual routes identified by this virtual route 
number to the specified destination subarea are displayed. There can be 
up to three virtual routes identified by virtual route number, with one 
route for each of the three transmission priority levels. 


If VR is specified, neither the COSNAME nor the ER operands may be 
specified. 


TEST=YES | NO 
specifies whether an explicit route test is to be performed. 


TEST=YES 


specifies that ACF/VTAM is to perform an explicit route test for each 
explicit route contained in the requested display. That is, if the VR 
operand is specified, the explicit route defined to be used by the 
specified virtual route is tested; if the COSNAME operand is specified, 
those explicit routes defined to be used by the virtual routes within the 
specified class of service are tested. The test results are sent to the 
operator requesting the display when they are received, but separately 
from the initial display results. The test results include a display 
number that allows the results to be correlated to the original status 
display. 


For an explicit route to be tested, it must be known to ACF/VTAM, 
either by having been defined at one time (through the activation of a 
path definition set defining the ER), or by having been operative at one 
time (through the receipt of an ER__OP request unit from the 
network). 


If a node or link along a route becomes inoperative after the ER test 
request unit has been sent, ACF/VTAM may never receive any test 
results for that explicit route. 


TEST=NO 


specifies that the requested route status is to be displayed, but that no 
explicit route test is to be performed. TEST=NO is the default value. 


DISPLAY STATIONS 


DISPLAY STATIONS Command 


To display the status of all cross-subarea link stations within each major node or 
a specific major node, enter: 


Operation Operands 


{DISPLAY | D} NET,STATIONS 
[ACT | EVERY | INACT] 
[,ID=major node name] 


STATIONS 
is a positional parameter and must appear immediately after NET. 


ACT | EVERY | INACT 
specifies the desired scope of the display. 


ACEF/VTAM treats resources in transition to or from the active state as 
“active” for the purposes of the display; otherwise the resources are 
considered to be “‘inactive.”’ 


ACT 
specifies that information is to be displayed about all active link stations 
within each major node, and their respective major nodes. 


ACT may be abbreviated as A. 


EVERY 
specifies that information is to be displayed about all link stations 
within each major node (regardless of their status), and their respective 
major nodes. 


EVERY is the default value; it may be abbreviated as E. 


INACT 
specifies that information is to be displayed about all inactive link 
stations within each major node, and their respective major nodes. 


INACT may be abbreviated as I. 


ID=major node name 
specifies the name of a major node. If this operand is specified, information 
is displayed only about the link stations within the specified major node. If 
this operand is omitted, information is displayed about the link stations in 
every active major node. 
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The resulting display indicates: 
e The name and subarea address for each physical unit type 4 or § (NCP or 
host subarea) that has subordinate link stations. 


e _ For each link station: 


= The name and status of the line. 
- The name and status of the link station. 
— The current transmission group number. 


~ The defined transmission group number. If no specific transmission 
| group number was defined, it is displayed as ‘‘0.”’ 


— The name (if known) and subarea (if known) of any adjacent NCP with 
which the link station is currently associated. 


DISPLAY TERMS 


DISPLAY TERMS Command 


Note: In a domain that has many terminals, this command might result in an 
undesirably large display, especially if the EVERY operand, which is the 
default, is used. 


To display the status of all device-type logical units (terminals) in active major 
nodes, enter: 


Operation 3 Operands 


{DISPLAY|D} = NET,TERMS 
. + oLACT|EVERY | INACT] 


ACT | EVERY | INACT 
specifies the desired scope of the display. 


ACF/VTAM treats resources in transition to or from the active state as 
“active” for the purposes of the display; otherwise the resources are 
considered to be “inactive.” 


ACT 
specifies that information is to be displayed about all active device-type 
logical units within each major node, and their respective major nodes. 
ACT may be abbreviated as A. 


EVERY 
specifies that information is to be displayed about ali device-type logical 
units within each major node (regardless of their status), and their 
respective major nodes. 


EVERY is the default value; it may be abbreviated as E. 


INACT 
specifies that information is to be displayed about all inactive 
device-type logical units within each major node, and their respective 
major nodes. 


INACT may be abbreviated as I. 


For each major node with terminals, the resulting display indicates: 


¢ The major node name 
e The line name and status (if the terminal is attached over a line) 
¢ The name and status of the associated physical unit (if any) 


e The name and status of the logical unit 
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DISPLAY TERMS 


Note: Physical units and logical units in a switched major node are always | 
listed under the switched major node and never under the NCP (and line) 
through which they are attached. To determine the name of this NCP major 


node or line, enter a DISPLAY [D=physical unit name or a DISPLAY 
[D=logical unit name command. 


DISPLAY U (MVS Only) 


DISPLAY U Command (MVS Only) 


To display the status of a TSO user ID, enter: 


Operation Operands 


{DISPLAY | D} NET,U,[D=userid 


ID=userid Sis 
specifies the TSO user ID about which information is to be displayed. 


The resulting display indicates the name and status of the TSO user ID, whether 
the TSO trace is active for this user ID, the application program name 
associated with the TSO user space, and the device-type logical unit the TSO 
user iS using. 
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In VSE systems, ACF/VTAM is started with the EXEC command. (OS/VS _ 
users should use the START command.) The EXEC command can be entered 
only at the system console. | | 


Operation Operands 


EXEC PROC=procname 


PROC=procname 
provides the name of the filed procedure that contains the JCL. needed to 
start and run ACF/VTAM. Written and named by the user, this start 
procedure should be on the VSE system procedure library (SYSPLB). For 
detailed information on the JCL needed for ACF/VTAM, see the 
ACF/VTAM Planning and Installation Reference manual. 


In the start option list (ATCSTROO), the system programmer can specify 
whether the ACF/VTAM operator is to be prompted to enter start options. If 
prompted, the operator can enter one or more: of the options listed below: 


CDRSCTI=n | 480 

COLD | WARM 
CONFIG=xx | 00 | name 
HOSTSA=n | 1 

IOINT=n | 180 

ITLIM=n | 0 

LIST=xx | 00 
MAXAPPL=n | 10 
MAXSUBA=n | 15 
MSGMOD=YES | NO 
NODELST=name 
SONLIM=([m | 60][,n | 30]) 
SSCPID=n 
SUPP=[NOSUP | INFO | WARN | NORM | SER] 


| TNSTAT[,CNSL | NOCNSL][, TIME=n | 60 ] | 


NOTNSTAT 
TRACE | NOTRACE,TYPE=BUF,ID=nodenamel,EVERY | E] 
TRACE | NOTRACE,TYPE=I10,ID=nodename[,EVERY | E] 
TRACE | NOTRACE,TYPE=LINE,ID=linename 
TRACE | NOTRACE,TYPE=SMS,ID=VTAMBUF 
TRACE,TYPE=VTAM[,MODE=INT | EXT] | 
[, OPTIONS =(options) | (APL.MSG,PI U) 
[.SIZE=nnn | 2] 
NOTRACE,TYPE=VTAM 
USSTAB=name 
VFBUF=vbsz 
VPBUF=vbsz 
VTAMEAS=n | 404 
poolname=(baseno,bufsize,slowpt,xpanno,xpanpt) 


EXEC (VSE Only) 


Enclose the group of options in parentheses, separate the options with commas, _ 
and leave no blanks between options. If more than one line is necessary for the 
start options, enter a comma after the last option and ACF/VTAM will prompt | 
for another line. The values established by the start options go into effect when 
ACF/VTAM is started and remain in effect until ACF/VTAM is halted. Many 
of the options, however, can be altered while ACF/VTAM is running. 


For a description of the start options, see the ACF /VTAM Planning and 
Installation Reference manual. | 
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The HALT command is used to request a normal halt of ACF/VTAM. . (See 
also the HALT CANCEL and HALT QUICK commands.) To halt _ 


ACF/% VTAM normally, enter: 


Operation Operands 


{HALT | Z} NET 
o [,CDLINK= ACT | INACT] - 


~ CDLINK=ACT | INACT 


specifies whether any active cross-domain SDLC links are to remain active 
after the NCPs have been deactivated. If the CDLINK operand is not 
specified, CDLINK=INACT is used. Therefore, if the CDLINK operand is 
omitted, the other domains’ cross-domain sessions might be disrupted. 


This option is effective only on the first HALT command. Any CDLINK 
specifications on subsequent HALT commands are ignored. 


CDLINK=ACT 
specifies that any active cross-domain SDILC links are to remain active 
after the NCP major nodes are deactivated, so that information being 
routed through the NCPs can continue to be so routed. That is, any 
cross-domain sessions that use the NCPs as transit nodes.can continue. 


CDLINK=INACT 
specifies that cross-domain SDLC links are to be deactivated, along 
with the rest of the domain. This disrupts any sessions through these 
cross-domain links. 


HALT CANCEL (OQS/VS Only) 


HALT CANCEL Command (OS/VS Only) 


The HALT CANCEL command applies only in OS/VS. In VSE systems, 
similar results can be obtained by canceling the ACF/VTAM partition. 


The HALT CANCEL command should be used only if the HALT and HALT 
QUICK commands do not work vroperly. This command depends only on the 
proper functioning of the operating system’s abnormal termination facilities. 


To cause the abnormal termination (ABEND) of ACF/VTAM, enter: 


Operation Operands 


{HALT | Z} NET,CANCEL 


The HALT CANCEL command results in an ABEND of ACF/VTAM with a 
system completion code of hex OA9. No further I/O operations are performed. 
Application programs using ACF/VTAM are notified of an ACF/VTAM 
shutdown with a TPEND exit, if possible, and data in the process of being 
transmitted might be lost. If TPEND cannot be scheduled, the application 
program is abnormally terminated. In extraordinary circumstances the operator 
might have to cancel some application programs. 
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The HALT QUICK command can be used to halt ACF/VTAM more quickly 
than with a normal HALT command. However, HALT QUICK disrupts 
I.U-to-LU sessions, as described in Chapter 2 under “HALT amd HALT 
QUICK Commands” and “‘Deactivating Resources.” 


To halt ACF/VTAM in this manner, enter: 


Operation Operands 


{HALT | Z} ~ NET,QUICK 
[.CDLINK=ACT | INACT] 


rece ereaeecmcitecimttn 


CDLINK=ACT | INACT 
specifies whether an any active cross-domain SDLC links are to remain active 
after the NCPs have been deactivated. If the CDLINK operand is not 
specified, CDLINK=INACT is used. Therefore, if the CDLINK operand is 
omitted, the other domains’ cross-domain sessions might be disrupted. 


This option is effective only on the first HALT command. Any CDLINK 
specifications on subsequent HALT commands are ignored. 


CDLINK=ACT 
specifies that any active cross-domain SDLC links are to remain active 
after the NCP major nodes are deactivated, so that information being 
routed through the NCPs can continue to be so routed. That is, any 
cross-domain sessions that use the NCPs as transit nodes can continue. 


CDLINK=INACT 
specifies that cross-domain SDLC links are to be deactivated, along 
with the rest of the domain. This disrupts any sessions through these 
cross-domain links. 


MODIFY ATTACH (VSE Only) 


MODIFY ATTACH Command (VSE Only) 


In VSE systems, certain IBM programs can be run as ACF/VTAM subtasks. 
To determine whether a particular program can be run as a subtask, see the 
documentation for that program. To attach a program as an ACF/VTAM 
subtask, enter: 


Operation Operands 


{MODIFY | F} NET,ATTACH,ID=name 


ATTACH 
specifies that a program is to be attached as an ACF/VTAM subtask. 


ID=name 
specifies the name of the program that is to be attached as a subtask. Two 
Or more programs can be active as ACF/VTAM subtasks at the same time, 
but they must be specified in separate MODIFY ATTACH commands. 
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The MODIFY CDRM command is used to tell ACF/VTAM which SSCP 
(CDRM) is the owner of a particular cross-domain resource (CDRSC) or set of 
CDRSCs. Ongoing sessions of CDRSCs affected by this command are not 
disturbed. The command changes the name of the external CDRM responsible 


for all future session setups with such CDRSCs. 


To change the CDRM associated with a CDRSC or set of CDRSCs, enter: 


Operation Operands 


{MODIFY | F} procname,CDRM=(new cdrm[,old cdrm]) 
[,[ID=cdrsc major node name | cdrsc minor node name] 


procname 
is the procedure name for the command. The procedure name is different 
for each operating system: 


In VSE systems, the procedure name is NET. 


In OS/VS2 (MVS) systems, the procedure name is the name of the 
procedure that was used to start ACF/VTAM. 


In OS/VS1 systems, the procedure name must be in the form procname .Pnn, 


where procname is the name of the procedure that was used to start 
ACF/VTAM and nn is a 1- or 2-digit decimal number that indicates the 
partition in which ACF/VTAM is running. 


CDRM=(new cdrmf,old cdrm]) 
indicates the new CDRM to be associated with the CDRSCs, and, 
optionally, the CDRM that it replaces. 


new cdrm 
specifies the name of the new CDRM that is to be associated with the 
CDRSC(s). 


old cdrm 
specifies the CDRM that was previously associated with the CDRSC(s). 
If old cdrm is specified, only the CDRM names that match this old cdrm 
name are changed. Otherwise (if old cdrm is not specified), the CDRM 
name is changed for the specified CDRSC(s), regardless of the previous 
value. 


ID=cdrse major node name | cdrsc minor node name 
specifies the name of the CDRSC major or minor node for which the 
owning CDRM name is to be changed (if permitted by the CDRM 
operand). If the ID operand is omitted, the command is applied to all 
CDRSCs known to ACF/VTAM. 


MODIFY CSALIMIT (MVS Only) 


MODIFY CSALIMIT Command (MVS Only) 


The size limit for ACF/VIAM’s use of the OS/VS2 (MVS) common service 
area (CSA) can be changed dynamically by the ACF/VTAM operator. 


To change the CSA limit, enter: 


Operation Operands 


{MODIFY | F} procname,CSALIMIT=(n | O[.F]) 


procname 
is the name of the proceduye that was used to start ACF/VTAM. 


CSALIMIT=(n | O[,F]) 
specifies the maximum amount of CSA storage to be used by ACF /VTAM. 


CSALIMIT=n 
specifies ACF/VTAM’s CSA use limit in units of 1024 bytes (K-bytes). 
That is, if CSALIMIT=4 is specified, ACF/VTAM will not usc more 
than 4096 bytes of CSA storage. The value specified should be a 
multiple of 4 and is rounded up, if necessary, to the next page size 
multiple, which is 4 K-bytes in MVS. 


Note that a request to change the CSA limit might be rejected 
depending on how the CSALIMIT start option was specificd and on the 
amount of storage currently allocated to ACF/VITAM. The operator 
can force the change to be accepted, however, with the l- operand, 
described below. 


CSALIMIT=0 
specifics that no limit on ACF/VTAM'’s use of CSA storage is to be 
enforced. 

F 


specifies that the value of is to be used as the CSA use limit 
regardless of how the CSALIMIT start option was specified or how 
much CSA storage is currently allocated to ACF/VTAM. If 
ACF/VTAM is currently using more CSA storage than the 
newly-specified limit, all subsequent CSA requests by ACF/VTAM 
components are rejected until the CSA allocation falls below that limit. 


If the F operand is not specified, a request to change the CSA limit is 
rejected if: 


¢ The CSALIMIT start option was omitted or CSALIMIT=0 was 
specified when ACF/VTAM was started. 


e The operator has specified a limit smaller than the amount of CSA 
storage currently allocated to ACF/VTAM. 


If the F operand is specified, these restrictions do not apply. 
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If a CSA limit is specified that is too low and the operator forces. this 
limit to take effect (by using the F operand), the operator will be 
effectively “locked out” of further ACF/VTAM command usage until 
the CSA usage falls below the specified limit, because CSA storage is 
needed to process all ACF/VTAM operator commands except HALT 
CANCEL. If the CSA usage does not fall below such a new level, 
ACF/VTAM must be canceled and restarted, with a more appropriate 
CSALIMIT value specified. 


MODIFY DETACH (VSE Only) 


MODIFY DETACH Command (VSE Only) 


In VSE systems, certain [BM-supplied programs can be run as ACF/VTAM 
subtasks. To detach a program that has been attached as an ACF/VTAM 
subtask, enter: 


Operation Operands 


{MODIFY | F} NET,DETACH,ID=name 


DETACH 
specifies that a program is to be detached as a subtask. This command can 
be entered during normal operation or while ACF/VTAM is halting. 


ID=name 
specifies the name of the program that is to be detached. If TPRINT is 
specified, ACF/VTAM invokes the TPRINT operator communication 
facility by converting the MODIFY DETACH command to a MODIFY 
MSG command. TPRINT can be terminated by responding CANCEL to 
the operator prompt. 
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To initiate a dump of an active NCP, enter: 


Operation Operands 


{MODIFY | F} procname,DUMP,ID=ncp name 


[,.DUMPSTA=name] 
[,DYNA | RMPO] 


procname 7 


is the procedure name for the command. The procedure name is different 
for each operating system: 


In VSE systems, the procedure name is NET. 


In OS/VS2 (MVS) systems, the procedure name is the name of the 
procedure that was used to start ACF/VTAM. 


In OS/VS1 systems, the procedure name must be in the form procname .Pnn, 
where procname is the name of the procedure that was used to start 
ACF/VTAM and nn is a 1- or 2-digit decimal number that indicates the 
partition in which ACF/VTAM is running. 


DUMP 


specifies that a dump operation is to be performed. 


1D=ncp name 


specifies the name of the NCP in the communication controller to be 
dumped. 


DUMPSTA=name 


specifies the name of a link station (channel or SDLC) in a node adjacent 
to the NCP to be dumped, through which the dump operation is to be 
performed. The link station must be active at the time of the dump. 


DUMPSTA does not apply if the DYNA operand is specified. 


If the DUMPSTA operand is specified, any previous DUMPSTA 
specifications (from the VARY ACT command or from the NCP definition) 
are overridden for this one dump operation. If a null value is specified (that 
is, if DUMPSTA= is specified), ACF/VTAM selects an available link 
station, giving preference to a channel link station over any SDLC link 
Stations. 


If the DUMPSTA operand is omitted, the current dump station name from 
the VARY ACT command or from the NCP definition (in that order) is 
used. If the current dump station name is null, ACF/VTAM selects an 
available link station as described above. 


MODIFY DUMP 


DYNA | RMPO 
provide additional specifications for the dump. DYNA and RMPO are 
mutually exclusive operands. If neither DYNA nor RMPO is specified, a 
normal static (destructive) dump is taken of the NCP and the NCP is 
deactivated. 


DYNA 
specifies that the NCP is to be dumped dynamically. That is, NCP 
processing is to continue during and after the dump. The NCP is not 
deactivated. The dump is taken by requesting 256 bytes at a time from 
the NCP, and the resulting output will reflect the storage contents of 
the communication controller over the period of time required to 
complete the dump. 


RMPO 
specifies that the communication controller containing the NCP is to be 
powered off after the NCP has been (statically) dumped and 
deactivated. RMPO should be entered only for an NCP that is in a 
communication controller with the remote power-off facility. 
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If the Encrypt/Decrypt Feature of ACF/VTAM is installed, logical units (both 
application programs and device-type logical units) can be defined to have one 
of several cryptography specifications defining the cryptographic capabilities or 
requirements that are to apply to any user sessions involving the logical units, as 
described in the ACF/VTAM Planning and Installation Reference manual. To 
change the cryptography specifications of a logical unit, enter: 


Operation Operands 


{MODIFY | F} procname,ENCR={OPT | REQD},ID=logical unit name 


procname 
is the procedure name for the command. The procedure name is different 
for each operating system: 


In OS/VS2 (MVS) systems, the procedure name is the name of the 
procedure that was used to start ACF/VTAM. 


In OS/VSI systems, the procedure name must be in the form procname .Pnn, 
where procname is the name of the procedure that was used to start 
ACF/VTAM and nn is a 1- or 2-digit decimal number that indicates the 
partition in which ACF/VTAM is running. 


ENCR={OPT | REQD} 
specifies the new cryptography specifications of the logical unit. The level 
of the cryptography specification may only be raised. Any attempt to lower 
the level is rejected. The new level is effective for all future sessions 
involving the logical unit; existing active or pending sessions are not 
affected. 


ENCR=OPT 
raises the level of the logical unit’s cryptography specification from no 
cryptography to optional (capable of cryptography). ENCR=OPT 
essentially has no effect for an application program logical unit, because 
its cryptographic capability is that of the host processor. 


ENCR=REQD 
raises the level of the logical unit’s cryptography specification from no 
cryptography or optional (or selective, for application programs) to 
required (that is, all user sessions must be encrypted). 


ID=logical unit name 
specifies the name of the logical unit whose cryptography specification is to 
be changed. The logical unit can be either an application program or a 
device-type logical unit. 


MODIFY [IMR 


MODIFY IMR Command 


Intensive mode recording (IMR) provides detailed information concerning 
temporary line errors or other hardware error conditions for a station on an 
SDLC link. IMR can be specified for a peripheral physical unit of an NCP or 
for a cross-subarea link station. 


To request or cancel intensive mode recording, enter: 


Operation Operands 


{MODIFY | F} procname,IMR,ID=link station or physical unit name 
[,OPT=ACT | INACT] 
[.RECLIM=n | 10] 


procname 
is the procedure name for the command. The procedure name is different 
for each operating system: 


In VSE systems, the procedure name is NET. 


In OS/VS2 (MVS) systems, the procedure name is the name of the 
procedure that was used to start ACF/VTAM. 


In OS/VSI systems, the procedure name must be in the form procname .Pnn. 
where procname is the name of the procedure that was used to start 
ACF/VTAM and nn is a 1- or 2-digit decimal number that indicates the 
partition in which ACF/VTAM is running. 


IMR 
identifies an intensive mode recording request. IMR is a positional 
parameter and must appear immediately after the procname operand. 


(D=link station or physical unit name 
specifies the name of the link station or physical unit for which IMR data is 
to be recorded. 


OPT=ACT | INACT 
specifies whether IMR should be started or stopped for the named link 
Station or physical unit. 


OPT=ACT 
specifies that IMR should be started for the named link station or 
physical unit. 


OPT=ACT is the default value. 


OPT=INACT 
specifies that ongoing intensive mode recording should be stopped, and 
that the NCP is not to generate any more IMR records for the named 
link station or physical unit. 
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RECLIM=n | 10 
specifies the maximum number of temporary errors that are to be recorded 
for the named link station or physical unit. When this limit is reached (or 
IMR is canceled with OPT=INACT) the NCP reverts to sending only 
permanent error records to ACF/VTAM. Any decimal integer in the range 
1 through 65535 can be specified. RECLIM | is not applicable if 
OPT=INACT is specified. 


RECLIM=10 is the default value. 
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MODIFY IOPD 


MODIFY IOPD Command 


This command allows the operator to change the I/O problem determination 
time-out interval. This interval determines how long certain ACF/VTAM I/O 
operations or internal procedures can remain pending before ACF/VTAM 
reports them to the operator. The operator can then decide whether a problem 
exists and what action, if any, is warranted. 


See ACF/VTAM Diagnosis Guide for guidance on setting the I/O problem 
determination time-out interval. 


To change the I/O problem determination time-out interval, enter: 


Operation Operands 


{MODIFY | F} procname,IOPD 
[ IOINT=n] 


procname 
is the procedure name for the command. The procedure name is different 
for each operating system: 


In VSE systems, the procedure name is NET. 


In OS/VS2 (MVS) systems, the procedure name is the name of the 
procedure that was used to start ACF/VTAM. 


In OS/VS1 systems, the procedure name must be in the form procname .Pna, 
where procname is the name of the procedure that was used to start 
ACF/VTAM and nn is a 1- or 2-digit decimal number that indicates the 
partition in which ACF/VTAM is running. 


IOPD 
indicates an I/O problem determination function request. IOPD is a 
positional parameter and must appear immediately after the procname 
operand. 


IOINT=n 
specifies the time-out interval (in seconds) for the [/O problem 
determination function. Specify m as a decimal integer in the range of 0 
through 5366000. IOINT=0 specifies that the I/O problem determination 
function is to be deactivated, meaning that ACF/VTAM will not notify the 
operator of pending I/O operations or internal procedures. If the L[OINT 
operand is omitted, the current time-out interval remains in effect. 
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MODIFY | LL2 Command 


The MODIFY LL2 command is used to request a link level 2 test for an SDLC 
link attached to an NCP. The link level 2 SDLC line test is used to test a 
communication line between an NCP and one of its peripheral physical units, or 
for a link between two NCPs. The test is performed by sending test data over 
the link from the controlling NCP to the remote station (NCP or peripheral 
physical unit), which is then echoed back to the sending NCP. This NCP then 
compares the data received with the data sent and forwards the results to 
ACF/VTAM. ACF/VTAM displays a message indicating the results. 


To request a link level 2 test enter: 


_ Operation a: Operands 


{MODIFY | Ft procname,LL2,1[D=name 
[,CANCEL | CONT | NFRANS=10 | m] 
[ DATA =data] | 
[ .NFRAMES=n | 1] 


procname | 
is the procedure name for the command. The procedure name is different 
for each operating system: 


In VSE systems, the procedure name is NET. 


In OS/VS2 (MVS) systems, the procedure name is the name of the 
procedure that was used to start ACF/VTAM. 


In OS/VSI1 systems, the procedure name must be in the form procname .Pnn, 
where procname is the name of the procedure that was used to start 
ACF/VTAM and nn is a 1- or 2-digit decimal number that indicates the 
partition in which ACF/VTAM is running. 
LL2 
indicates a request for a link level 2 test. LL2 is a positional parameter and 
must appear immediately after the procname operand. 


ID=name 
specifics: 


¢ For a test of a link between two NCPs, the name of a link station on 
the link that is to be tested. The specified link station must be in the 
NCP that is to initiate the test. The link stations at each end of the 
link must both be inactive. 


¢ For a link between an NCP and a peripheral node, the name of a 
physical unit on the link that is to be tested. The specified physical unit 
must be inactive, but, for a multi-point link, the other physical units on 
the link can be active during the test. 


Users of ACF/NCP/VS Release 2 should refer to ““Link Level 2 Test” in 
Chapter 2 for migration considerations. 
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MODIFY LL2 


CANCEL | CONT | NTRANS=10 | m 
indicates either how many test messages are to be sent on the link or that a 
current test is to be halted. NTRANS=10 is the default value. 


CANCEL 
specifies that the currently running test should be stopped. 


CONT 
specifies that the test should run continuously until canceled by the 
ACF/VTAM operator. 


NTRANS=10|n 
indicates the number of test messages that are to be sent. Specify any 
decimal integer in the range 1 through 65534. (Specifying 
NTRANS=65535 is effectively the same as specifying CONT.) 


DATA=data 
specifies optional user data to be used as part of the test message. Any 
EBCDIC alphabetic, numeric, or special characters (such as @ # $) can be 
‘specified. The maximum number of characters permitted depends on the 
characteristics of the device at the receiving end of the test. If the DATA 
operand is omitted, ACF/VTAM sends test messages without user data. 


NFRAMES=n | 1 
specifies (for a multipoint line) the number of test messages that are to be 
sent to the physical unit each time its station is selected. This option allows 
the test messages to be interleaved with other data going to other stations 
on a multipoint line. Specify any decimal integer in the range 1 through 
65535. NFRAMES=1 is the default value. 
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After an IBM-supplied subsystem is attached as an ACF/VTAM subtask (see 
the MODIFY ATTACH command), the operator communication facility of the 


-subtask can be invoked, if the subtask has one. This command can be used to 


request that an attached subtask issue a prompting message so that the 
ACF/VTAM operator can submit a command to the subtask. 


To invoke the operator communication facility in a subtask, enter: 


Operation | Operands 


{MODIFY | F} NET,MSG,ID=subtask name 


MSG 
specifies that an attached subtask is to prompt the operator. MSG is a 
positional parameter and must appear immediately after the NET operand. 


{[D=subtask name 
specifies the phase name of the active subtask. 


MODIFY MSGMOD 


MODIFY MSGMOD Command 


ACF/VTAM allows the operator to specify whethcr ACF/VTAM messages 
should contain an identifier that indicates which ACF/VTAM module originated 
the message. If specified, this function puts the last five characters of the name 
of the issuing module immediately after the message identifier. 


Caution: If the addition of this identifier would cause the message text to exceed 
the maximum allowable message length, the message is truncated on the right, with 
the possible loss of information. 


! 


To specify whether ACF/VTAM messages should contain this identifier, enter: 


Operation Operands 


{MODIFY | F} procname,MSGMOD={YES | NO} 


procname 
is the procedure name for the command. The procedure name is different 
for each operating system: 


In VSE systems, the procedure name is NEV. 


In OS/VS2 (MVS) systems, the procedure name is the name of the 
procedure that was used to start ACF/VTAM. 


In OS/VSI systems, the procedure name must be in the form procname .Pnn, 
where procname is the name of the procedure that was used to start 
ACF/VTAM and nn is a 1- or 2-digit decimal number that indicates the 
partition in which ACF/VTAM is running. 

MSGMOD ={YES | NO} 
specifies whether ACF/VTAM messages should contain an issuing-module 
identifier. 


MSGMOD=YES 
specifies that ACF/VTAM messages should contain an issuing-module 
identifier. 

MSGMOD=NO 
specifies that ACF/VTAM messages should not contain an 
issuing-module identifier. 
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This command can be used to change the negative polling limit (the maximum 
number of consecutive negative polling responses accepted before polling 
another terminal on the line) in an NCP for a nonswitched, polled line to one or 
more attached BSC 3270 terminals. 


To change the negative polling limit, enter: 


Operation Operands 
{MODIFY | F} procname, NEGPOLL=number of responses,[D=line name 
procname 


is the procedure name for the command. The procedure name is different 
for each operating system: 


In VSE systems, the procedure name is NET. 


In OS/VS2 (MVS) systems, the procedure name is the name of the 
procedure that was used to start ACF/VTAM. 


In OS/VSI1 systems, the procedure name must be in the form procname .Pnn, 
where procname is the name of the procedure that was used to start 
ACF/VTAM and nn is a 1- or 2-digit decimal number that indicates the 
partition in which ACF/VTAM is running. 


NEGPOLL=number of responses 
specifies the negative polling limit as a decimal integer in the range of | 
through 255. This is the maximum number of consecutive negative polling 
responses accepted before polling another terminal on the line specified by 
the [ID operand. | 


{D=line name 
specifies the name of a nonswitched, polled line to one or more attached 
BSC 3270 terminals. 


MODIFY NOTNSTAT 


MODIFY NOTNSTAT Command 


See also the MODIFY TNSTAT command and the TNSTAT | NOTNSTAT start 
option. 


To stop the recording of tuning statistics, enter: 


Operation Operands 


{MODIFY | F} procname,NOTNSTAT 


procname 
is the procedure name for the command. The procedure name is different 


for each operating system: 
In VSE systems, the procedure name is NreT. 


In OS/VS2 (MVS) systems, the procedure name is the name of the 
procedure that was used to start ACF/VTAM. 


In OS/VS'1 systems, the procedure name must be in the form procname .Pnn, 
where procname is the name of the procedure that was used to start 
ACF/VTAM and nn is a 1- or 2-digit decimal number that indicates the 
partition in which ACF/VTAM is running. 


NOTNSTAT 
specifies that the recording of tuning statistics is to be stopped. 
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See ACF/VTAM Diagnosis Guide for a more detailed description of the 
ACF/VTAM trace facilities. See also the MODIFY TRACE command and the 
TRACE | NOTRACE start option. 


To stop an ACF/VTAM trace, enter: 


Operation Operands 


{MODIFY | F} procname, NOTRACE,TYPE={BUF | IO},[D=name 
[ EVERY] 


procname, NOTRACE,TYPE={LINE | SMS | TG | TSO} 
,{D=name 


procname, NOTRACE, TYPE=VTAM 
[,OPTION=ALL | option | (option,...,option) | END] 


procname 
is the procedure name for the command. The procedure name is different 
for each operating system: 


In VSE systems, the procedure name is NET. 


In OS/VS2 (MVS) systems, the procedure name is the name of the 
procedure that was used to start ACF/VTAM. 


In OS/VS1 systems, the procedure name must be in the form procname .Pnn, 
where procname is the name of the procedure that was used to start 
ACEF/VTAM and nn is a 1- or 2-digit decimal number that indicates the 
partition in which ACF/VTAM is running. 


NOTRACE 
stops the trace specified by the TYPE operand. 


TYPE={BUF | IO | LINE | SMS |TG|TSO|VTAM} 
specifies the kind of trace that is to be stopped. Each trace must be 
stopped with a separate MODIFY NOTRACE command. 


TYPE=BUF 
specifies stopping the tracing of text that passes through ACF/VTAM 
buffers on the way to or from the node indicated by the ID operand. 
Optionally, the EVERY operand can be used to extend the scope of the 
trace to all nodes subordinate to the specified node. 


TYPE=IO 
specifies stopping a trace of I/O activity associated with the node 
indicated by the ID operand. Optionally, the EVERY operand can be 
used to extend the scope of the trace to all nodes subordinate to the 
specified node. In addition, for an NCP major node with an active 
channel attachment, the EVERY operand terminates any active channel 
I/O trace. 


MODIFY NOTRACE 


TYPE=LINE 
specifies stopping an NCP line trace for the line indicated by the ID 
operand. 


Caution: Specifying TYPE=LINE stops any transmission group trace that was 
Started using the same fine name. 


TYPE=SMS 
specifies stopping a storage management services (SMS) trace that is 
recording ACF/VTAM buffer pool usage data. 

TYPE=TG 
specifies stopping an NCP transmission group trace for the transmission 
group containing the line indicated by the ID operand. 

TYPE=TSO 
specifies stopping a TSO component trace for the user ID indicated by the 
ID operand. 

TYPE=VTAM 

specifies stopping the ACF/VTAM internal trace for the components 

specified by the OPTION operand. If CPTION is omitted, no internal 
traces are stopped; rather, ACF/VTAM issucs messages identifying the 
components for which the internal trace is currently active. 


ID=name 
specifies the name of a node or TSO user ID for which there is an active 
trace of the type specified by the TYPE operand. 

EVERY 
This operand applies only for TYPE=BUF or TYPE=I!IQO. It specifies that 
the traces for any nodes subordinate to the node specified are to be 
stopped. 


EVERY may be abbreviated as E. 


OPTION=option | (option,...,option) | ALL | END 
This operand applies only for TYPE=VTAM. It indicates the types of 
ACF/VTAM internal traces to be stopped. OPTION may be abbreviated 
as OPT. 


If TYPE=VTAM is specified and OPTION is omitted, ACF/VTAM issues 
messages identifying the components for which the internal trace is active, 
without stopping any active traces. 
OPTION =option | (option,...,option) 

specifies the types of ACF/VTAM internal traces to be stopped. 

Specify one or more of the following: 

API Application program interface 

CIO Channel I/O for channel-attached devices 

LOCK Locking 

MSG Messages 


PIU Path information units 


PSS Process scheduling services 
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SMS Storage management services 
SSCP — System services control point 


If more than one option is selected, separate them with commas and 
enclose the list in parentheses. 


OPTION=ALL 
specifies that all internal ACF/VITAM trace activity is to be stopped. 
It is equivalent to specifying all of the internal trace types shown above. 


OPTION=END 
specifies that all internal ACF /VTAM trace activity is to be stopped, 
and the internal irace table is to be freed (with consequent loss of 
existing trace data if external recording is not being used). 
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MODIFY POLL Command 


This command can be used to change the polling delay (the time delay between 
polling sequences) in an NCP for a nonswitched, polled line to one or more 
attached BSC 3270 terminals. 


To change the polling delay, enter: 


Operation Operands 


{MODIFY | F} procname,POLL=n,ID=line name 


procname 
is the procedure name for the command. The procedure name is different 
for each operating system: 


In VSE systems, the procedure name is NET. 


In OS/VS2 (MVS) systems, the procedure name is the name of the 
procedure that was used to start ACF/VTAM. 


In OS/VS1 systems, the procedure name must be in the form procname .Pnn, 
where procname is the name of the procedure that was used to start 
ACE/VTAM and nn is a 1- or 2-digit decimal number that indicates the 
partition in which ACF/VTAM is running. 


POLL=n 
specifies the polling delay in tenths of a second. This is the time delay 
between polling sequences on the line specified by the ID operand. Specify 
n as a decimal integer in the range of 0 through 255. 


ID=line name 
specifies the name of a nonswitched, polled line to one or more attached 
BSC 3270 terminals. 


wn 
tod 
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This command can be used to change the session limit (the maximum number of 
concurrent line scheduling sessions allowed) in an NCP for a nonswitched, 
polled line to one or more attached BSC 3270 terminals. 


Normally the limit that is set should be no greater than the maximum number of 
terminals on the line. This limit does not become effective until the number of 


sessions now in operation falls below the new limit. 


To change the session limit, enter: 


Operation Operands 


SMODIPY | F} procname,SESSION=n,[D=line name 


procname 
is the procedure name for the command. The procedure name is different 


for each operating system: 
In VSE systems, the procedure name is NET. 


In OS/VS2 (MVS) systems, the procedure name is the name of the 
procedure that was used to start ACF/VTAM. 


In OS/VSI1 systems, the procedure name must be in the form procname .Pnn, 
where procname is the name of the procedure that was used to start 
ACEF/VTAM and nn is a 1- or 2-digit decimal number that indicates the 
partition in which ACF/VTAM is running. 


SESSION=n 
specifies the session limit as a decimal integer in the range of 1 through 
255. This is the maximum number of concurrent line scheduling sessions 
allowed on the line specified by the ID operand. 


ID=line name 
specifies the name of a nonswitchced, polled line to one or more attached 
BSC 3270 terminals. 
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MODIFY SUPP Command 


To change the message suppression level after ACF/VTAM has been started, 


enter: 

Operation Operands 

{MODIFY | F} procname,SUPP={NOSUP | INFO| WARN |NORM]|SER} 
procname 


is the procedure name for the command. The procedure name is different 
for each operating system: 


In VSE systems, the procedure name is NET. 


In OS/VS2 (MVS) systems, the procedure name is the name of the 
procedure that was used to start ACK/VITAM. 


In OS/VSI1 systems, the procedure name must be in the form procname .Pri, 
where procname is the name of the procedure that was used to start 
ACE/VTAM and nn is a 1- or 2-digit decimal number that indicates the 
partition in which ACF/VTAM is running. 


SUPP={NOSUP | INFO | WARN | NORM | SER} 
specifics the suppression Ievel for ACF/VITAM messages. 


SUPP=NOSUP 
specifies that no ACI-/VIfAM messages are to be suppressed. 


SUPP=INFO 
specifies that only those ACF/VTAM messages classified as 
informational messages are to be suppressed. 


SUPP=WARN 
specifies that those ACF/VTAM messages classified as warning 
messages, as well as informational messages, are to be suppressed. 


SUPP=NORM 
specifies that those ACF/VTAM messages classified as normal 


messages, as well as warning and informational messages, arc to be 
suppressed. 

SUPP=SER 
specifies that those ACF/VTAM messages classified as serious error 
messages, as well as normal, warning, and informational messages, are 
to be suppressed. 
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Note that some error messages, such as those indicating abnormal termination 
of a task, are classified as “‘unsuppressible” and cannot be suppressed. Other 
messages that cannot be suppressed include those requiring a response from the 
ACE/VTAM operator (messages with a system classification of A) and those 
resulting from the operutor’s status inquiries (messages resulting from a 
DISPLAY command). | 


See the ACF/VTAM Messages and Codes manual for a definition of these 
message catagories and the classifications of specific ACK /VTAM messages. 
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MODIFY TEST Command 


The Teleprocessing Online Test Executive Program (TOLTEP) is a component 
of ACF/VTAM that is used to test selected hardware in an ACF/VTAM 
domain. To invoke TOLTEP from the ACF/VTAM operator's console, enter: 


Operation Operands 


{MODIFY | F} procname, TEST 


procname | 
is the procedure name for the command. The procedure name is different 


for each operating system: 
In VSE systems, the procedure name is NET. 


In OS/VS2 (MVS) systems, the procedure name is the name of the 
procedure that was used to start ACI’ /VITAM. 


In OS/VS1 systems, the procedure name must be in the form procname .Pan, 
where procname is the name of the procedure that was used to start 
ACE/VTAM and nan is a 1- or 2-digit decimal number that indicates the 
partition in which ACF/VTAM is running. 

TEST | 


specifies that TOLTEP is to be invoked for the testing of selected hardware 
in the domain. 


Notes: 


Il. Terminals should not be activated or deactivated while TOLTEP is 
using them. 


2. If TOLTEP abnormally terminates prior to the termination of 
ACF/VTAM, ACF/VTAM automatically restarts TOLTEP. 


3. Although TOLTEP can be invoked from the operator's console, it 
cannot be used to test the operator's console itself. Only selected 
hardware that is part of the ACF/VTAM domain can be tested by 
TOLTEP. See ACF/VTAM Diagnosis Guide for a list of the devices 
that can be tested by TOLTEP. 


Chapter 4. ACF/VTAM Operator Commands 137 


MODIFY TNSTAT Command 


ACF/VTAM provides a facility whereby tuning statistics can be recorded about 
some of ACF/VTAM’s activities. These statistics can be used to adjust 
ACF/VTAM and NCP variables to improve performance. For more 
information on using tuning statistics, see the ACF/VTAM Planning and 
Installation Reference manual. 


If this facility is to be used, the TNSTAT start option must have been specified 
when ACF/VTAM was started. Additionally, in an OS/VS system, the System 
Management Facility (SMF) must have been included in the system during 
system generation. To change or restart the recording of tuning statistics, enter: 


Operation Operands 


{MODIFY | F} procname,TNSTAT 
| [,CNSL | NOCNSL] 
[, TIME=n] 


procname 
is the procedure name for the command. The procedure name is different 
for each operating system: 


In VSE systems, theprocedure name is NET. the procedure name is NET. 


In OS/VS2 (MVS) systems, the procedure name is the name of the 
procedure that was used to start ACF/VTAM. 


In OS/VS1I systems, the procedure name must be in the form procname .Pnn, 
where procname is the name of the procedure that was used to Start 
ACF/VTAM and nn is a 1- or 2-digit decimal number that indicates the 
partition in which ACF/VTAM is running. 


TNSTAT 
specifies that tuning statistics recording is to be started. 


CNSL | NOCNSL 
specifies where the tuning statistics are to be recorded. 


CNSL | 
specifies that tuning statistics records are to be sent to the system 
console as well as to the SMF data set (in OS/VS) or the trace file (in 
VSE systems). 


NOCNSL 
specifies that tuning statistics records are to be sent only to the SMF 
data set (in OS/VS) or the trace file (in VSE systems). NOCNSL is 
the default value. 


138 


MODIFY TNSTAT 


TIME=n 
specifies the number of minutes between tuning statistics recording events 
as a decimal integer in the range 1 through 1440. If the TIME parameter is 
not specified, the time value specified in the TNSTAT start option remains 
in effect. 
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MODIF Y TPRINT Command (VSE Only) 


. The MODIFY TPRINT command attaches the trace print utility as a subtask of 


ACF/VTAM. When the MODIFY TPRINT command is entered to print 
specified trace records on the ACF/VTAM external trace file, all externally 
recorded tracing is suspended and does not resume until the appropriate trace 
records have been printed, but tracing continues internally, with possible 
wraparound and overlaying of trace data. 


The ACF/VTAM trace facility records trace records in wraparound fashion 
either in main storage or in a trace file assigned to a disk or tape. If the trace 
file is on a disk or tape, the operator is notified when the end of the trace file is 
reached. When a trace file is full, or the main storage buffer (when no file is 
used) is full, the oldest records are overlayed by new trace records. Therefore. 
if trace data is being produced faster than TPRINT can print it, trace data is 
lost due to wraparound. 


The handling of ACF/VTAM internal trace records is different from the 
handling of other trace records in that the trace print utility does not 
automatically print any internal trace records that are presently in its internal 
trace table. To guarantee that the ACF/VTAM internal trace records are 
complete (if they are being externally recorded), enter MODIFY 
NET,NOTRACE,TYPE=VTAM,OPT=END to terminate the trace or 
MODIFY NET,TRACE,TYPE=VTAM,MODEEINT,SIZE=nn to switch the 
recording of data to an internal trace table of size nn (sec MODIFY TRACE 
for a full description of the SIZE operand). 


Vo initiate trace printing, enter: 


Aa NL SRR ENA ae Ane Eb 


Operation Operands 


{MODIFY | F} NET,PPRINT 


This command specifies that the ACF/VTAM trace print utility is to be used. 
After the MODIFY TPRINT command has been entered, ACF/VITAM promnipts 
the operator (with messages 5KO7A and 5KOSA) to request a snapshot print or 
to select print options as described below. The snapshot print does not apply to 
ACF/VTAM internal trace records. 


A snapshot print of the contents of ACF/VTAM’s main storage trace buffers 
containing the most recently recorded trace records can be selected without 
suspending trace recording. If SYSOO1 is assigned to a file, the operator is 
prompted to select either a snapshot print of ACF/VTAM’s trace buffers or the 
full edit and print process. If ACF/VTAM is tracing with no external recording 
(SYSOO1 is unassigned), a buffer snapshot is automatically performed. A 
snapshot print of ACF/VTAM’s internal trace buffer is not available. 


Records can be printed only in the order in which they appear in the trace file. 


Trace Print Options 
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For a trace printout, SYSLST must be assigned to a printer, tape, or disk with 
the name IJSYSLS. If SYSOO1 is assigned to a tape device, ensure that an 
unlabeled scratch tape is mounted and ready before entering the first MODIVY 
TRACE command. 


The operator can cancel the trace print that was started by the MODIT'Y 
TPRINT command by entering CANCEL when ACF/VTAM issues prompting 
messages. The command MODIFY NET,MSG,ID=TPRINT can be entered to 
cause a prompting message to be issued. | 


The operator replies to this prompting mlcssdbe we One or more of the options 
described below as “Trace Print Options.” 


When ACF/VTAM prompts the operator (Message S5KOSA: ENTIER PPRINT 
OPTIONS OR ‘CANCEL.’) to enter the TPRINT options, any combination of 
these options can be entered: 


CANCEL 
specifies that the trace print utility is to be canceled. 


PRINT | 
specifies that trace records, described by the options below, are to be 
printed. If only PRINT is entered, all buffer contents and 1/O trace records 
are printed. 7 


BUF=ALL 
specifies that all buffer contents trace records are to be printed. 


BUF=namel,...,name] 
specifies that the buffer contents trace records are to be printed for: 
VTAM, an NCP, a physical unit (including switched and channel-attached 
SNA physical units), a logical unit (including application programs), a 
channel-attached non-SNA terminal, a CDRM, or a CDRSC. 


CLEAR=YES | NO 
specifies where ACF/VTAM is to resume recording information after the 
printing of the trace is completed. This option applies only for an online 
trace, which suspends tracing until the appropriate trace records have been 
printed. 


CLEAR=YES causes the tracing to start at the beginning of the file. 
This causes the trace records to be overlayed by new trace records. 


CLEAR=NO causes the tracing to continue after: the last record 
recorded. 


CLEARE=NO is the default value. 


INTERVAL=beginning time | (,end time) | (beginning time,end time) » 
specifies that only the trace records produced during a specific time interval 
are to be printed. Records can be requested by specifying either the time at 
which tracing began, the time at which tracing ended, or the time at which 
tracing began and ended. All trace recording and selection use Greenwich 
Mean Time. | 
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Specify the time in one of the following formats: 


yy.ddd/hh:mm:ss 
yy.ddd 


hh:mm:ss 


where yy indicates the year, ddd indicates the day, hh indicates the hour, 
mm. indicates the minute, and ss indicates the second. 


[0O=ALL 
specifies that all I/O trace records are to be printed. 


l1O=namel,...,zname] 
specifies that the records tracing I/O activity are to be printed for: VTAM, 
an NCP, a physical unit (including switched and channel-attached SNA 
physical units), a logical unit (including application programs), a 
channel-attached non-SNA terminal, a CDRM, or a CDRSC. 


LINE=ALL | 
specifies that all the NCP line trace records recorded while the lines were 
operating in network control mode are to be printed. 


LINE=name 
specifies that the NCP line trace records for the named line operating in 
network control mode are to be printed. 


TNST=ALL 
specifies that all tuning statistic records are to be printed. 


TNST=namel,...,name] 
specifies that name or names of the NCP major nodes for which the tuning 
Statistic records are to be printed. 


VIT 
specifies that all ACF/VTAM internal trace records are to be printed. 


The total number names specified on the BUF, IO, LINE, and TNST options 
for each MODIFY TPRINT command or job step must not exceed 50. (The 
BUF=ALL, IO=ALL, LINE=ALL, TNST=ALL options are not counted in 
this limit.) Commas are required between the option specifications and between 
the names specified for each option. If additional lines of options are to be 
entered, end the current line with a comma, and, when prompted (message 
SKO6A: ENTER ADDITIONAL OPTIONS OR ‘CANCEL’), continue entering 
options. 
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MODIFY TRACE Command 


The MODIFY TRACE command can be used to start traces or modify the 
parameters for currently running traces. Also see the description of the 
MODIFY NOTRACE command. (ACF/VTAM traces can also be started or 
stopped with the TRACE | NOTRACE start option, as described in the 
ACF/VTAM Planning and Installation Reference manual.) 


For a complete description of when to use these traces and how to interpret the 
results, see ACF/VTAM Diagnosis Guide. 


To start a trace, enter one of the following: 


Operation Operands 
{MODIFY | F} procname, TRACE,TYPE={BUF | IO},ID=name[,EVERY] 


procname, TRACE,TYPE={LINE | SMS | TG | TSO} 
D=name 


procname, TRACE,TYPE=VTAM 

[ MODE=INT | EXT] 

[,OPTION=option | (option,...,option) | ALL] 
[ SIZE=nnn] 


procname 
is the procedure name for the command. The procedure name is different 
for each operating system: 


In VSE systems, the procedure name is NET. 


In OS/VS2 (MVS) systems, the procedure name is the name of the 
procedure that was used to start ACF/VTAM. 


In OS/VS1 systems, the procedure name must be in the form procname .Pnn, 
where procname is the name of the procedure that was used to start 
ACF/VTAM and nn is a 1- or 2-digit decimal number that indicates the 
partition in which ACF/VTAM is running. 


TRACE 
starts the type of trace specified by the TYPE operand. 


TYPE={BUF | IO | LINE | SMS |TG|TSO|VTAM} 
specifies the kind of trace that is to be started. More than one kind of 
trace can be active at the same time, but each trace must be started with a 
separate MODIFY TRACE command. 


TYPE=BUF 
specifies starting the tracing of text that passes through ACF/VTAM 
buffers on the way to or from the node indicated by the ID operand. 
Optionally, the EVERY operand can be used to extend the scope of the 
trace to all nodes subordinate to the specified node. This trace is useful 
only when at least one of the logical units in the session is an 
application program in this domain. 
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TYPE=IO | : a er 
specifies starting a trace of I/O activity associated with the node 
indicated by the ID operand. Optionally, the EVERY operand can be 
used to extend the scope of the trace to all nodes subordinate to the 
specified node. In addition, for an NCP major node with an active 
channel attachment, the EVERY operand provides a trace of all I/O 
going across the channel, including cross-domain session I/O. 


TYPE=LINE 
specifies starting an NCP line trace for the line indicated by the ID 
operand. : 


TYPE=SMS 
specifies starting a storage management services (SMS) trace to record 
ACE/VTAM buffer pool usage data. 


TYPE=TG 
specifies starting an NCP transmission group trace for the transmission 
group containing the line indicated by the ID operand. A line is part of 
a transmission group only when both the line and its subordinate link 
station are active. A transmission group trace can be started by naming 
any line within the transmission group. Once a transmission group trace 
is started, another trace of the same transmission group cannot be 
requested by naming the same or another line within the transmission 
group in another MODIFY TRACE command. 


If the line or its link station subsequently fails or is deactivated (that is, 
if the line is removed from the transmission group), the transmission 
group trace is ended, even though the transmission group continues to 
operate if there are any remaining lines in the transmission group. The 
trace can be restarted, naming another line in the transmission group. 


The NCP line trace and the transmission group trace are mutually 
exclusive for a particular line. Therefore, when starting a transmission 
group trace, select a line that is not being used, and is not likely to be 
used, for a line trace. 


TYPE=TSO 
specifies starting a TSO component trace for the user ID indicated by 
the ID operand. GTF must be active when this trace option is 
specified. 


TYPE=VTAM 
specifies starting of the ACF/VTAM internal trace for the components 
specified by the OPTION operand. If OPTION is omitted, no new 
component internal traces are initiated; rather, ACF/VTAM issues 
messages identifying the components for which internal trace is 
currently active. 


EVERY 


This operand applies only for TYPE=BUF or TYPE=IO. It specifies that 
traces are to be started for all nodes subordinate to the specified node. 
Nodes for which trace does not apply are not traced. 


For an I/O trace of a channel-attached NCP, the EVERY operand provides 
a trace of all channel I/O, including network message traffic routed through 
the channel-attached NCP. 


EVERY may be abbreviated as E. 
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ID=name 
specifies the name of the resource for which tracing is to be done. Only 
active resources can be traced. This operand does not apply for 
TYPE=VTAM. 


Names of various types of resources can be specified, depending on the 
value of the TYPE operand. 


For TYPE=BUF or TYPE=IO 
Any of the following names can be specified with the EVERY option to 
trace message activity with the named resource, if applicable, and all of 
the resource’s subordinate nodes: 


e The name of a major node 

e The name of a line group 

e The name of a line 

e The name of a physical unit (including switched and 


channel-attached SNA physical units) 


Any of the following names can be specified to trace message activity 
with the named resource: 


«  VTAM (for a trace of all SSCP-FMCB sessions). 
« The name of an NCP 


e The name of a physical unit (including switched and 
channel-attached SNA physical units) 


« The name of a logical unit (including application programs) 
e The name of a channel-attached non-SNA terminal 

e The name of a CDRM (only in a multiple-domain network) 
e The name of a CDRSC (only in a multiple-domain network) 


For TYPE=LINE 


The ID operand specifies the name of the line for which tracing is to be 
done. 


For TYPE=SMS 
ID=VTAMBUF must be specified for an SMS trace. 


For TYPE=TG 
The ID operand specifies the name of a line currently within the 
transmission group to be traced. All the lines in the transmission group 
are traced as if they were a single logical line. 


For TYPE=TSO 
The ID operand specifies the TSO user ID for which tracing is to be 
done. 


MODE=INT | EXT 
This operand applies only to TYPE=VTAM. It specifies whether 
ACF/VTAM internal trace is to record its data on an internal, wraparound 
table (MODE=INT) or on an external trace file (MODE=EXT). 
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Once the ACF/VTAM internal trace is started, the MODE operand does 
not have a default. If successive MODIFY commands change other options, 
the MODE specification remains the same until respecified on a MODIFY 
command. The default, MODE=INT, applies only when the internal trace 
is started as a start option or when a MODIFY TRACE,TYPE=VTAM 
command is entered to start the trace after it has been stopped. 


In OS/VS systems, the generalized trace facility (GTF) USR trace must be 
activated before starting a trace with MODE=EXT. 


In OS/VS systems, the MODE=EXT and SIZE operands are mutually 
exclusive. 


In VSE systems, MODE=INT can be used prior to starting the TPRINT 
utility program to guarantee that the TPRINT output will be complete. The. 
external file is the TRFILE to which SYSOOQ1 has been assigned. 
MODE=EXT significantly increases the amount of storage needed for 
TRFILE. It might be necessary to increase the file’s disk storage or to use 
tape. Loss of data due to overrun conditions also can be avoided by 
increasing the SIZE value specified and by selecting a device that will not 
be slowed by channel or disk contention with other high priority functions 
such as paging. If there is no TRFILE (SYS001 is unassigned), the 
MODE=EXT operand is invalid. 


OPTION=option | (option,...,option) | ALL 


This operand applies only to TYPE=VTAM. It indicates the ACE/VTAM 
components for which the trace is to be started. OPTION may be 
abbreviated as OPT. 

If TYPE=VTAM is specified and OPTION is omitted, ACF/VTAM issues 


messages identifying the components for which the internal trace is active, 
without stopping any active traces. 


OPTION=option | (option,...,option) 
specifies the ACF/VTAM components for which the internal trace is to 
be started. Specify one or more of the following: 
API Application program interface 
CIO Channel I/O for channel-attached devices 


LOCK Locking 


MSG __ Messages 


PIU Path information units 
PSS Process scheduling services 
SMS Storage management services 


SSCP System services control point 
See “Traces” in Chapter 2 for operating considerations regarding traces. 
If mote than one option is selected, separate them with commas and 


enclose the list in parentheses. For information on what is traced for 
each component, refer to ACF/VTAM Diagnosis Guide. 
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OPTION=ALL 
specifies that the ACF/VTAM internal trace is to be started for all of 
the ACF/VTAM components for which the ACF/VTAM internal trace 
is available. [t is equivalent to specifying all of the internal trace types 
shown above. 


SIZE=nan 
This operand applies only to TYPE=VTAM. The use of this operand is 
different for OS/VS and VSE systems. 


In OS/VS systems 
The SIZE operand can be specified only when MODE=INT is specified. 
The SIZE operand specifies the number of pages to be allocated for the 
internal trace table. Integers from | through 999 can be specified. 


In VSE systems 
The SIZE operand has different meanings for MODE=INT and 
MODE=EXT. 


When MODE=INT is in effect, the SIZE operand specifies the number 
of pages to be allocated for the internal trace table. Integers from | 
through 999 can be specified. 


When MODE=EXT is in effect, the SIZE operand specifies the number 
of 2K-byte buffers to be used in writing records on the trace file. If the 
default value of SIZE=2 results in a loss of data (for example, because 
data is coming into the buffers faster than it can be written out), the 
operator should increase the SIZE value. When MODE=EXT is in 
effect, the maximum value for SIZF is 32. If the value specified is 
greater than that, ACF/VTAM uses SIZE=372. 


If the size of the trace table is changed while MODE=EXT is in effect, 
the current table contents are written to the trace file before the old 
table is freed. 


Once the ACF/VTAM internal trace is started, the SIZE operand does not 
have a default. If successive MODIFY commands change other options, the 
SIZE specification remains the same until respecified on a MODIFY 
command. The default valuc, SIZE=2, applies only when the internal trace 
is started as a start option or when a MODIFY TRACE,TYPE=VTAM 
command is entered to start the trace after it has been stopped. 


Caution: If MODE=INT is in effect and the SIZE value is too small, trace 
information might be destroyed because of wraparound in the internal trace 
table. In addition, if the SIZE operand specifies a size different from the 
current table size (specified on a previous command or start option), 
information will be lost because the trace table is freed when another table 
with a new size is obtained. 
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In OS/VS systems, ACF/VTAM is started with the START command. (VSE 


users should use the VSE system EXEC command.) The START command can 


be entered only at the master or a secondary system console. 


Operation Operands 


{START | S} procname[,,,(options,...)] | 
procname | 


is the name of the filed procedure that contains the JCL needed to start and 
run ACF/VTAM. Written and named by the user, this procedure should be 
on SYS1.PROCLIB. For detailed information on the JCL needed for 
ACF/VTAM, see the ACF/VTAM Planning and Installation Reference 
manual. 


In OS/VS1 systems, procname must be in the form procname .Pnn, where nn 
is a one- or two-digit decimal number that indicates the partition in which 
ACF/VTAM is to run. 


options 
are ACF/VTAM start options supplied by the system programmer. The 
ACF/VTAM operator can enter one or more of the options listed below: 


CDRSCTI=n | 480 

COLD | WARM 

CONFIG=xx | 00 | name 

CSALIMIT=n|0 (MVS only) 

DLRTCB=n | 8 (OS/VS1 only) 

DLRTCB=n | 32 (MVS only) 

HOSTSA=n | 0 

IOINT=n | 180 

ITLIM=n|0 

LIST =xx | 00 

MAXAPPL=n | 10 

MAXSUBA=n | 15 

MSGMOD=YES | NO 

NODELST=name 

SONLIM=(m | 60,n | 30) 

SSCPID=n 

SUPP=NOSUP | INFO | WARN | NORM | SER 
TNSTAT[,CNSL | NOCNSL][,TIME=n | 60] 

Fete 

TRACE | NOTRACE,TYPE=BUF,ID=nodename|,EVERY | E] 

TRACE | NOTRACE, TYPE=IO,ID=nodename[,EVERY | E] 

TRACE | NOTRACE, TYPE=LINE,ID=linename 

TRACE | NOTRACE,TYPE=SMS,ID=VTAMBUEF 
TRACE, TYPE=VTAM[,MODE=INT | EXT] 

] 


[, OPTIONS = (options) | (API,LMSG,PIU) | ALL 
[| SIZE=nnn | 2] 
NOTRACE,TYPE=VTAM 


START (OS/VS Only) 


USSTAB=name 
VTAMEAS =n | 404 
poolname=(baseno,bufsize,slowpt,F,xpanno,xpanpt) 


Precede the option list with three commas, enclose the group of options in 
parentheses, and separate the options with commas. Do not leave any 
blanks between options. If more than one line is necessary for the start 
options, enter a comma after the last option and ACF/VTAM will prompt 
for another line. The values established by the start options go into effect 
when ACF/VTAM is started and remain in effect until ACF/VTAM is 
halted. Many of the options, however, can be altered while ACF/VTAM is 
running. 


For a description of the start options, see the ACF/VTAM Planning and 
Installation Reference manual. 
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The VARY ACQ command is used to acquire an NCP, or to acquire a 
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physical unit attached by a nonswitched line to an NCP. An NCP ora 
physical unit can be acquired as part of a backup and recovery procedure 
in a multiple-domain network. A physical unit can also be acquired as 
part of a switched network backup procedure in either a single- or 
multiple-domain network. | : 


The purpose of the VARY ACQ command is to: 


1. Acquire ownership of NCP resources that are normally owned by another 
host (this kind of acquire, which requires that the Multisystem Networking 
Facility be installed, is performed with an NCP that has previously been 
activated). 


2. Acquire ownership of all resources within an NCP, including the NCP itself 
(this kind of acquire, which requires that the Multisystem Networking 
Facility be installed, can be performed only with an inactive NCP attached 
through an active SDLC link station in an adjacent subarea node). 


3. Acquire ownership of an individual physical unit and its logical units. 


Acquiring resources within an NCP makes them known to ACF/VTAM until 
the NCP is released or deactivated; acquiring a physical unit makes it usable by 
the acquiring host and makes its logical units known until the physical unit is 
released. See Chapter 3 for descriptions of possible backup and recovery 
procedures using the VARY ACO command. 


The VARY ACQ command can also be entered for a physical unit when 
terminating a switched network backup procedure. The purpose of the VARY 
ACQ is to make a nonswitched physical units’s logical units known to 
ACF/VTAM after a switched physical unit definition (representing the same 
physical device with a different physical unit name but with the same logical 
unit names) is deactivated. See Chapter 3 for a description of the switched 
network backup procedure. 


To acquire an NCP or a physical unit, enter: 


Operation Operands 
{VARY | V} NET,ACO,ID=name 
AACTL,LLOGMODE=logon mode name] 
[, LOGON=application program name or cdrsc name 
[ SCOPE=ALL | COMP | ONLY | U] 


ACQ 
specifies that the resource identified by the ID operand is to be acquired. 


ID=name 
specifies the name of the resource that is to be acquired. The resource must 
be either an NCP major node or a physical unit within an NCP major node. 


VARY ACQ 


ACT 
specifies that the acquired resources should also be activated. 


For an NCP major node, ACT specifies that acquired subordinate 
resources of the NCP should be activated, according to the value of 
the SCOPE operand. (The NCP itself is always activated or is 
already active when VARY ACQ is used.) 


For a physical unit, ACT specifies that the acquired physical unit and 
its subordinate resources should be activated according to the value of 
the SCOPE operand. 


The scope of the ACT command can be specified by the SCOPE 
operand. 


The following operands apply only if ACT is specified. 


LOGMODE=logon mode name 
specifies the logon mode name to be used for any logon initiated for a 
logical unit as a result of this command (see the description of the 
LOGON operand). This logon mode name also becomes the logon mode 
name for all future automatic logons performed by ACF/VTAM, for 
logical units within the scope of this command, to their controlling 
application programs (if any). 


If LOGMODE is not specified, the LOGMODE value specified in any 
previous command applicable to a logical unit also within the scope of 
this current VARY ACQ command is used. If no LOGMODE value was 
ever specified for a given logical unit within the scope of this command, 
the logical unit’s default value is used. 


LOGON<=application program name or cdrsc name 
specifies the name of an application program to which any logical units 
within the scope of this command are to be logged on. If the application 
program is in this domain, the name must be that of an application 
program minor node within an active application program major node. If 
the application program is located in another domain, the name must be 
that of a CSRSC minor node within an active CDRSC major node. 


See also the description of the VARY LOGON command for more 
information on the operator-initiated logon function. 


~ SCOPE=ALL | COMP | ONLY |U 
specifies the scope of the command. 


SCOPE=ALL 
indicates that all of the acquired subordinate resources of the 
resource named in the ID operand are to be activated (regardless of 
their defined ISTATUS values). 
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SCOPE=COMP 
_ indicates that the acquired subordinate resources of the resource 
named in the ID operand are to be activated in a manner comparable 


to the way they would be activated in ACF/VTAM Release 1 or 
VTAM Level 2. 


SCOPE=COMP is the default valine: 


SCOPE=ONLY 
indicates that none of the acquired subordinate resources of the resource 
named in the ID operand are to be activated at this time (regardless of their 
defined ISTATUS values); only the resource named in the ID operand is to 
be activated (except that, as explained under the ACT operand, an NCP 
name specified in the ID operand is always activated or is already active, 
regardless of the ACT and SCOPE operands). 


SCOPE=U 
indicates that the acquired subordinate resources of the resource named in 
the ID operand are to be activated according to their defined ISTATUS 
values. 
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VARY ACT Command 


The VARY ACT command is used to activate ACF/VTAM resources. The 
different resource types that can be activated are specified in the table below. 


Operation Operands 


{VARY | V} NET,ACT,ID=name 
[ ANS=ON | OFF] 
[,.DUMPSTA=name] 
| LOAD=YES | NO | U] 
[ LOADSTA=name] 
[ LOGMODE=logon mode name] 
{ LOGON=application program name or cdrsc name] 
[ RNAME=name | (namel,...,name13)] 
[SCOPE=ALL | COMP] ONLY | U] 
{,U=channel device name] 
[ WARM] 


The following table indicates each resource type for which the command is valid 
and which operands can be used on the command. A bullet (+) indicates that 
the operand applies to that resource and an S indicates that the operand can be 
specified for sifting to subordinate resources. An M indicates that the operand 
applies to that resource only in certain migration cases. 
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ACT | : | | 
specifies that the named resource is to be activated. 


ID=name | . | 
specifies the name of the resource to be activated. If the name specifies a 
resource that has subordinate resources (for example, the logical units 
subordinate to a physical unit), the subordinate resources might also be 
activated, depending on the specification of the SCOPE or WARM operand 
(these operands are described later in this chapter). 


ANS=ON | OFF | 
specifies whether a switched SDLC line is to be put in answer mode. 


ANS=ON 
specifies that a switched SDLC line is to be put in answer mode. When 
the line is in answer mode (and active), the NCP answers incoming calls 
from dial-in devices and notifies ACF/VTAM of the calls so that 
sessions can be established. 


ANS=OFF 
specifies that a switched SDLC line is to be taken out of answer mode. 
If there is an existing session for the line, ANS=OFF does not break 
the session, but no further calls are accepted after the session ends. 


DUMPSTA=name | 
applies only to the first activation of an NCP. (That is, DOUMPSTA does 
not apply if the NCP is already active or is in the process of being 
activated.) 


DUMPSTA specifies the name of a link station in an adjacent subarea node 
through which any later static dump operations for this NCP are to be 
carried out. The link station can be either a channel link station or an 
SDLC link station. The name specified for DUMPSTA should also be 
specified in the channel device name or RNAME specifications for this 
NCP, either in the NCP definition or in this VARY ACT command. 


The DUMPSTA operand, if specified, overrides any NCP definition value of 
DUMPSTA. If DUMPSTA is specified neither in the NCP definition nor in 
this command, ACF/VTAM selects (at the time of each dump operation) 
an available adjacent link station, giving preference to a channel link 
station. Similarly, if DUMPSTA is specified without a value (that is, if 
DUMPSTA= is specified), DUMPSTA assumes a null value and | 
ACF/VTAM selects an available adjacent link station as previously 
described. 


LOAD=YES | NO|U 


applies only to the first activation of an NCP. (That is, LOAD does not 
apply if the NCP is already active or is in the process of being activated.) 


LOAD specifies whether the communication controller associated with the 

specified NCP is to be reloaded with the appropriate NCP load module. A 
communication controller is “associated with’ an NCP for the purposes of 

this command if any of the following conditions are met: 


e It is already known to contain the named NCP. 
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e {tis attached through one or more of the adjacent link stations 
identified by the NCP’s channel device name or RNAME specifications, 
or both. | 


e It is attached through the adjacent link station identified by the 
LOADSTA specification for the NCP. 


LOAD=YES 
specifies that the communication controller associated with the specified 
NCP is to be unconditionally loaded, regardless of the current state or 
contents of the communication controller. 


LOAD=NO 
specifies that the communication controller associated with the specified 
NCP is not to be loaded during the processing of this VARY ACT 
command, regardless of the current state or contents of the 
communication controller. (The communication controller is still 
subject to possible reload operations during error recovery procedures 
subsequent to the activation of the NCP.) If the communication 
controller does not contain the expected NCP load module, the VARY 
ACT command fails. 


LOAD=U 
specifies that ACF/VTAM is to determine whether the communication 
controller associated with the specified NCP is to be loaded during the 
processing of this VARY ACT command (based on the current contents 
of the communication controller and on the NCP definition statements), 
as it did before the availablity of the LOAD operand. 


LOAD=U is the default value. 


LOADSTA=name 
applies only to the first activation of an NCP. (That is, LOADSTA does 
not apply if the NCP is already active or is in the process of being 
activated.) 


LOADSTA specifies the name of a link station in an adjacent subarea node 
through which any load operations for this NCP are to be carried out. The 
link station can be either a channel link station or an SDLC link station. 
The name specified for LOADSTA should also be specified in the channel 
device name or RNAME specifications for this NCP, either in the NCP 
definition or in this VARY ACT command. 


The LOADSTA operand, if specified, overrides any NCP definition value of 
LOADSTA. If LOADSTA is specified neither in the NCP definition nor in 
this command, ACF/VTAM selects (at the time of each reload operation) 
an available adjacent link station, giving preference to a channel link 
station. Similarly, if LOADSTA is specified without a value (that is, if 
LOADSTA= is specified), LOADSTA assumes a null value and 
ACF/VTAM selects an available adjacent link station as previously 
described. 


LOGMODE=logon mode name 
specifies the logon mode name to be used for any logon initiated for a 
logical unit as a result of this command (see the description of the LOGON 
operand). This logon mode name also becomes the logon mode name for 
all future automatic logons performed by ACF/VTAM, for logical units 
within the scope of this command, to their controlling application programs 
(if any). 
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If LOGMODE is not specified, the LOGMODE value specified in any 
previous command applicable to a logical unit also within the scope of this 
VARY ACT command is used. If no LOGMODE value was ever specified 


default value is used 


_ for a given logical unit within the scope of this command, the logical unit’s 


LOGON=application program name or cdrsc name 


specifies the name of an application program to which any logical units 
within the scope of this command are to be logged on. If the application 
program is in this domain, the name must be that of an application program 
minor node within an active application program major node. If the 
application program is located in another domain, the name must be that of 
a CSRSC minor node within an active CDRSC major node. 


See also the description of the VARY LOGON command for more 
information on the operator-initiated logon function. 


RNAME=name | (namel,...,name13) 


applies either to the activation of an NCP or, in certain migration cases, to 
the activation of a link station. For information on using RNAME when 
activating a link station, see the migration considerations described in 
‘“Cross-Subarea Link Failures” in Chapter 3. 


For an NCP, the RNAME operand is described in the following paragraphs 
and applies only to the first activation of the NCP. (That is, RNAME docs 
not apply if the NCP is already active or is in the process of being 
activated.) 


RNAME specifies the names of up to 13 SDLC link stations in adjacent 
subarea nodes through which the specified NCP is attached to the network. 
It also specifies which SDLC link stations (and associated links) in adjacent 
subarca nodes are to be automatically activated as part of the activation of 
the specified NCP. Therefore, these RNAME values identify the location 
of the communication controller in the network and allow ACE /VTAM to 
establish the necessary connectivity to the specified NCP (if such 
connectivity does not already exist). 


If more than one link station name is specified, the names must be enclosed 
in parentheses and separated by commas. 


The RNAME operand, if specified, overrides any NCP definition RNAME 
values or the checkpointed RNAME values for the specified NCP. If 
RNAME values are specified on this command, ACF/VTAM uses those 
values to determine the link stations to be used. If the RNAME: operand is 
not specified in this command, ACF/VTAM uses the checkpointed 
RNAME values for the specified NCP Gif the WARM operand is specified). 
If neither the RNAME nor the WARM operands are specified, 
ACF/VTAM use the NCP definition values for RNAME, if any. If 
RNAME is not specified in the NCP definition, RNAME assuines a null 
value, and no SDLC link stations are automatically activated. If the 
RNAME operand is specified without a value (that is, RNAME= is 
specified), RNAME assumes a null value. 


If both the RNAME and the channel device name specifications have nuil 
values, no automatic link station activations are performed, and there must 
be link stations already active in adjacent subarca nodes to provide the 
required connectivity. If this is not the case, the VARY ACT command 
fails. 


VARY ACT 


SCOPE=ALL | COMP | ONLY | U 
specifies the scope of the command. 


WARM and SCOPE cannot be specified on the same command. If both are 
specified, the command fails. 


If the SCOPE operand is used, any vaiues for the checkpointed parameters 
for this resource are ignored and erased. 


SCOPE=ALL 
indicates that the resource named in the ID operand and all of the 
appropriate subordinate resources are to be activated (regardless of 
their defined ISTATUS values). 


SCOPE=COMP | 
indicates that the resource named in the ID operand and the appropriate 
subordinate resources are to be activated in a manner comparable to the 
way they would be activated in ACF/VTAM Release 1 or VTAM 
Level 2. 


SCOPE=COMP is the default value. 


SCOPE=ONLY 
indicates that only the resource named in the ID operand is to be 
activated; none of its subordinate resources are to be activated at this 
time (regardless of their defined ISTATUS values). 


SCOPE=U 
indicates that the resource named in the ID operand and all of the 
appropriate subordinate resources defined with ISTATUS=ACTIVE are 
to be activated. 


U=device name 
applies only to the first activation of a channel-attached NCP or SNA 
physical unit. (That is, the U operand does not apply to an NCP or 
physical unit that is already active or is in the process of being activated.) 


The U operand specifies the channel device name by which a channel 
attachment to a communication controller or SNA physical unit is known to 
the operating system and through which ACF/VTAM is to establish 
connectivity to the specified NCP or physical unit. A channel device name 
must be supplied for a channel-attached physical unit because the physical 
unit can communicate only through the channel. A channel device name is 
optional for an NCP because an NCP can also communicate across SDLC 
links. 


For an SNA Physical Unit 
The U operand, if specified, overrides any previous channel device name 
specifications for the physical unit, including the CUADDR operand on 
the PU definition statement and any specification maintained by 
configuration restart. 


If the U operand is omitted and there is no current channel device name 
specification for the physical unit, the VARY ACT command fails. The 
VARY ACT command also fails if the U operand is specified without a 

value (that is, if U= is specified). | 
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For an NCP OO _ | 

The U operand, if specified, overrides any NCP definition CUADDR 
values or the checkpointed channel device name values for the specified 
NCP. If a U value is specified on this command, ACF/VTAM uses the 
value to determine the link station to be used. If the U operand is not 
specified in this command, ACF/VTAM uses the checkpointed channel 
device name values for the specified NCP (if the WARM operand is 
specified). If neither the U nor the WARM operands are specified, 
ACF/VTAM use the NCP definition value for CUADDR, if any. If °¢ 
CUADDER is not specified in the NCP definition, the channel device 
name specification assumes a null value, and no channel link station is 
automatically activated. If the U operand is specified without a value 
(that is, if U= is specified), the channel device name specification 
assumes a null value. 


If both the RNAME and the channel device name specifications have 
null values, no automatic link station activations are performed, and 
there must be link stations already active in adjacent subarea nodes to 
provide the required connectivity. If this is not the case, the VARY 
ACT command fails. 


WARM | 
applies only to major nodes (except application program major nodes) and 
specifies that the major node specified in the ID operand is to be activated 
to the status it had when it was last active. That is, those minor nodes that 
were active the last time the major node was active are reactivated, and 
other operator-modified values applicable to the major node or its minor 
nodes (such as controller application name and logmode name for a logical 
unit) are restored. By recording changes in a configuration restart file, 
ACF/VTAM keeps track of the status of the minor nodes as well operator 
changes to other checkpointed parameters. For a list of the checkpointed 
parameters for each major node and for a general description of the 
configuration restart facility, see the ACF/VTAM Planning and Installation 
Reference manual. 


The WARM parameter is invalid and the VARY ACT command fails in the 
following circumstances: 

¢ WARM and SCOPE are specified on the same command. 

« WARM is specified for a major node that is already active. 


¢ WARM is specified when activating a major node that has no associated 
VSAM configuration restart file or whose configuration restart file has 
not been used (that is, contains no checkpointed information). 


VARY ANS 


VARY ANS Command 


Active switched SDLC lines with dial-in capability can allow or disallow an 
incoming call from a physical unit defined in a switched major node. For an 
incoming call to be allowed, an active line must be in answer mode. 


The mode setting can be specified in the definition statement for the line and 
can be changed whenever the line is active by using this command. The mode 
setting of a line can also be specified when the line is activated (see the 
description of the ANS operand on the VARY ACT command). 


The VARY ANS command is most often used for lines with both dial-in and 
dial-out capability. To ensure that a line is available for dial-out requests, it can 
be taken out of answer mode while it is still active. Incoming calls are blocked, 
but outgoing calls proceed normally. 


To change the mode setting, enter: 


Operation Operands 
SVARY | V} NET.ANS={ON | OFF},ID=line name 
[ACT] 


ANS=ON | OFF 
specifies whether the line is to be put in answer mode. 


ANS=ON 
specifies that the line is to be put in answer mode. When a line is in 
answer mode (and active), the answering subarea node accepts an 
incoming call from a dial-in device and notifies ACF/VTAM of the call 
so that sessions can be established. 


ANS=OFF 
specifies that the line is to be taken out of answer mode. If there is an 
existing session using the line, ANS=OFF does not break the session, 
but no further incoming calls are accepted after the session ends. 


ID=line name 
specifies the name of an SDLC line. The line must be a switched line with 
dial-in capability. The line must also be active, unless the ACT operand is 
also specified on this command. 

ACT 
specifies that the line is to be activated as well as have its answer mode 
setting changed. If ACT is not specified, the line must be active before the 
VARY ANS command is entered. 
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If the physical configuration of a communication controller is changed (for 


example, a physical unit is moved from one line to another), the NCP residing 

in the communication controller can be reconfigured without having to generate 
a new NCP. A previously-filed set of statements called a dynamic 
reconfiguration (DR) file must be available before the NCP can be reconfigured. 
For information on creating a DR file, see the ACF/VTAM Planning and 
Installation Reference manual. 


To dynamically reconfigure an NCP, the NCP must be active. Any logical units 
in the existing configuration that are to be affected by the reconfiguration must 
be inactive. The physical units to which these logical units are subordinate must 
also be inactive. 


Those minor nodes which are dynamically added to an NCP configuration as a 
result of this command are also activated if the DR definition file defines their 


initial status as ‘‘active.”’ 


To dynamically reconfigure an NCP, enter: 


Operation Operands 
{VARY | V} NET,DRDS,ID=drname 
DRDS 


specifies that an NCP major node is to be dynamically reconfigured. 


ID=drname 
specifies the name of a dynamic reconfiguration file. 
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VARY INACT Command 


The VARY INACT command is used to deactivate ACF/VTAM resources. 
The different resource types that can be deactivated are specified in the table 
below. 


Caution:. TSO/VTAM< users should never use this command to deactivate a TSO 
user address space application name while TSO/VTAM is operating. 


Operation Operands 


{VARY | V} NET, INACT,ID=name 
[,CDLINK=ACT | INACT] 
[ ,FINAL] 
[I] FIR] 
[ RMPO] 


The following table indicates each resource type for which the command is valid 
and which operands can be used on the command. A bullet (+) indicates that 
the operand applies to that resource. An I, F, or R in the table indicates what 
value is subsituted if an F or R operand is specified for a resource to which it 


does not apply. 
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INACT | 


specifies that the resource specified in the ID operand, and all of its 
subordinate resources, is to be deactivated (with the exception of 
same-domain cross-subarea links and link stations within an NCP to be 
deactivated). For normal deactivation, do not specify I, F, or R. Normal 
deactivation does not break existing sessions but does prevent the 
establishment of new sessions with nodes within the scope of this command. 


Refer to Chapter 2 for special considerations involving the deactivation of 
links and link stations. 


ID=name 


specifies the name of any active major or minor node that is to be 
deactivated. 


CDLINK=ACT | INACT 


applies only to the deactivation of an NCP. It specifies whether active 
cross-domain links and link stations are to remain active after the NCP 
major node is deactivated. 


This option is effective only on the VARY INACT or VARY REL 
command which begins the deactivation of an NCP. For example, if a 
second VARY INACT (perhaps with the I operand specified) is entered 
before the first VARY INACT command completes, CDLINK does not 
apply to the second command and is ignored if specified. 


Refer to Chapter 2 for special considerations involving the deactivation of 
links and link stations. 


CDLINK=ACT 
specifies that active cross-domain links and link stations are to remain 
active after the NCP major node is deactivated, so that sessions routing 
information through the NCP over such links can continue without 
disruption. | 


CDLINK =INACT | 
specifies that cross-domain links and link stations are to be deactivated 
as part of the NCP deactivation. Any session traffic over such links 
might be disrupted, depending on whether such links and link stations 
are also owned by some other host. Refer to the descriptions of links 
and link stations in Chapter 2 for a discussion of how shared ownership 
affects the results of deactivating a link or link station. 


CDLINK=INACT is the default value. 


FINAL 


specifies that the physical unit specified in the ID operand is no longer 
required and that there are no immediate plans to reactivate it. The actual 
effects of this operand are device-dependent, and could include such 
functions as automatic power-off. See the applicable component description 
manual for the specific effects of a DACTPU type X‘01’ command on a 
particular device. For physical units in a local SNA or switched major 
node, FINAL is meaningful only if the physical unit is fully active prior to 
beginning the deactivation. 


I|F|R 


specifies the type of deactivation (other than normal deactivation). If 
neither I, F, nor R is specified, normal deactivation occurs. 


VARY INACT 


specifies that the specified resource and applicable subordinate 
resources are to be deactivated immediately. 


If 1 is specified, sessions involving the affected resources are disrupted, 
but ACF/VTAM waits for application programs being deactivated, or 
application programs in session with resources being deactivated, to 
formally end their sessions (that is, issue CLSDST) before completing 
the deactivation. 


The I operand can be specified on a VARY INACT command centered 
while a normal deactivation is in progress. 


specifies that the specified resource and applicable subordinate 
resources are to undergo forced deactivation. This type of deactivation 
might be advisable for resources that do not respond to normal or | 
immediate (1) deactivation requests, or that are preventing complction 
of an ACF/VTAM HALT command. A forced deactivation instructs 
ACF/VTAM to deactivate its internal representations of the applicable 
resources and to send appropriate deactivation commands to the 
resources or their superior nodes, without waiting for responses to these 
commands. Therefore, a forced deactivation of a resource could result 
in a mismatch between ACF/VTAM's record of the status of a resource 
and the actual status of the resource in the network. 


If F is specified, sessions involving the resources are disrupted, and 
ACF/VTAM might have to wait (depending on how a given application 
program is coded) for application programs being deactivated, or 
application programs in session with resources being deactivated, to 
formally end their sessions (that is, issue CLSDST) before completing 
the deactivation. 


The F operand can be specified on a VARY INAC'T command entered 
while a normal or immediate deactivation or an ACF /VTAM halt is in 
progress. | 


specifies that the specified resource and applicable subordinate 
resources are to undergo forced deactivation and subsequent reactivation. 
This type of deactivation and reactivation might be advisable for 
resources that are not responding to ACF/VTAM commands, but that 
the operator desires to remain active. A forced reactivation instructs 
ACF/VTAM to deactivate its internal representations of the applicable 
resources and to send appropriate deactivation commands to the 
resources or their superior nodes, waiting for responses before beginning 
reactivation. If any of the resources still do not respond, a VARY 
INACT command with the F operand should be entered to force 
deactivation of those resources. 


If R is specified, sessions involving the resources are disrupted, and 
ACF/VTAM might have to wait (depending on how a given application 
program is coded) for application programs being deactivated, or 
application programs in session with resources being deactivated, to 
formally end their sessions (that is, issue CLSDST) before completing 
the deactivation and beginning reactivation. 
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Any type of deactivation request (normal, immediate, or forced) can be 
entered while a forced reactivation is in progress, if termination of the 
reactivation is desired. As previously stated, forced deactivation might 
be the only effective deactivation method if a resource fails to respond 
to the forced reactivation. 


RMPO 


applies only to an NCP major node and specifies that the communication 
controller in which the NCP is running is to be automatically powered-off at 
the completion of the deactivation. The communication controller must 
support the remote power off feature for this operand to be effective. 


VARY INOP 


VARY INOP Command 
The VARY INOP command can be used to terminate: 


¢ A manual dial-out operation, if the ACF/VTAM operator is unable to 
complete the call 


e A session request for a channel-attached SNA logical unit, if its physical 
unit is not to be made available on the host channel 


Terminating a Manual Dial Operation: A physical unit in a switched major 
node can be dialed either automatically or manually to establish a session with a 
logical unit. For manual dialing, ACF/VTAM issues a message containing the 
following information: 


e The name of the line that ACF/VTAM will try to use to make the 
connection. The line must be a switched line with dial-out capability. 


¢ The telephone number that the ACF/VTAM operator is to dial. This 
number is the number specified in the DIAILNO operand of the appropriate 
PATH statement associated with the physical unit that the operator is 
dialing. 


After receiving this information, the ACF/VTAM operator must try to make 
the connection by dialing the specified telephone number. If the operator is 
unable to complete the connection, the operator should enter the VARY INOP 
command either to ask ACF/VTAM to search for an alternate path or to ask 
ACF/VTAM to terminate the session request without a search for an alternate 
path. 


Terminating a Session Request for a Channel-Attached Logical Unit: If 
ACF/VTAM needs the ACF/VTAM operator’s assistance in creating a 
connection to a physical unit in a local SNA major node, ACF/VTAM displays 
the message IST680I (OS/VS) or 5G80I (VSE). This message indicates that a 
connection request was denied because the physical unit is offline. The 
connection request remains pending and the operator should either allow the 
connection request to complete by making the device available on the line, or 
disallow the connection request by entering a VARY INOP command for the 
physical unit. 


Command Syntax: 


Operation Operands 


{VARY | V} NET,INOP ),ID=line name[,END] 
ID=physical unit name 
INOP 


specifies that this is either a manual dial-out operation for a switched 
physical unit or a session request for a channel-attached logical unit. 


Chapter 4. ACF/VTAM Operator Commands 165 


VARY INOP 


166 


{D=line name 


applies only for a connection request to a switched physical unit, and 
specifies the name of the line used to attempt the manual dial connection. - 
This name is included in the ACF/VTAM message requesting manual 
dialing. | : 


ID=physical unit name 


applies only for a channel-attached physical unit, and specifies the name of 
that physical unit. This name is included in the ACF/VTAM message 
indicating that the connection request was denied. 


END 


applies only for a connection request toa switched physical unit. It 
specifies that there is to be no search for an alternate line. If END is not 
specified, ACF/VTAM séarches for another appropriate line to the physical 
unit. | : _ 


VARY LOGON 


VARY LOGON Command 


The VARY LOGON command is used to change an existing automatic logon 
specification or to create an automatic logon specification where one does not 
exist. This command applies to any device-type logical unit, whether 
channel-attached or link-attached. Neither the logical unit nor the application 
program to receive the automatic logon has to be active when the VARY 
LOGON command is issued. Their respective major nodes, however, must be 
active. If the application program is located in another domain, the application 
program major node in the other domain must also be active. 


An automatic logon specification remains in effect until another VARY 
LOGON command (or any other VARY command with the LOGON operand) 
is entered, or until the major node containing the logical unit is deactivated. 
Any automatic logon request made as a result of this specification might be 
accepted or rejected by the application program. 


The VARY LOGON command only specifies an application program session 
partner for automatic logon (when the specified logical unit becomes available 
for a session); it does not activate the logical unit. To activate the logical unit 
(or a resource to which the logical unit is subordinate) and change the 
automatic logon specification at the same time, use the VARY ACT command 
with the LOGON operand. 


Also see the VARY ACO and VARY ACT commands with the LOGON 
operand. 


To change the automatic logon specification for a logical unit or a group of 
logical units, enter: 


Operation Operands 
{VARY | V} - NET,LOGON=application program name or cdrsc name, 
ID=name 


[| LOGMODE=logon mode name] 


LOGON=application program name or cdrsc name 
specifies the name of an application program to which any logical units 
within the scope of this command are to be logged on. If the application 
program is in this domain, the name must be that of an application program 
minor node within an active application program major node. If the 
application program is located in another domain, the name must be that of 
a CSRSC minor node within an active CDRSC major node. — 


A logical unit not already owned by an application program can be logged 
on to the Teleprocessing Online Test Executive Program (TOLTEP) for 
testing if ISTOLTEP is specified as the application program name. 


ID=name : 
specifies the name of a device-type logical unit or the name of a resource 
with subordinate device-type logical units. (This command does not apply 
to CDRSCs or CDRSC major nodes.) Only logical units are affected by 
VARY LOGON commands. If another resource type is specified, the 
logical units affected are those subordinate to the resource that is specified 
on the command. 
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LOGMODE=logon mode name 


specifies the logon mode name to be used for any logon initiated for a_ 
logical unit as a result of this command. This logon mode name also 
becomes the logon mode name for all future automatic logons performed by 
ACF/VTAM, for logical units within the scope of this command, to their 
controlling application programs (if any). 


If LOGMODE is not specified, the LOGMODE value specified in any 
previous command applicable to a logical unit also within the scope of this 
current VARY LOGON command is used. If no LOGMODE value was 
ever specified for a given logical unit within the scope of this command, the 
logical unit’s default value is used. 


Also see the VARY ACQ and VARY ACT commands with the LOGON 
operand. 


VARY PATH 


VARY PATH Command 


This command is used to modify the availability of a dial-out path to a specific 
switched physical unit or a group of dial-out paths within a switched major 
node. 


A physical unit in a switched major node can be dialed through one or more 
dial-out paths associated with the physical unit. Switched path control is 
initially established in a switched major node definition by the USE operand of 
the PATH statement associated with a physical unit. Unless USE=NO has 
been specified, the path is automatically enabled for use by ACF /VTAM when 
the physical unit is activated. 


Note: The PATH statement refered to in this command description is in the 
switched major node definition; do not confuse it with the PATH macre 
instructions used to define a path definition set. 


Dial-out path usage can be altered by enabling or disabling: 


e A single dial-out path to the physical unit (represented by a PID) 


e A logical group of dial-out paths in the same switched major node 
(represented by a GID) 


To modify the availabilty of a dial-out path, enter: 


Operation Operands 
{VARY | V} NET,PATH=USE | NOUSF 
»PID=n,ID=physical unit name 
s<GID=n,ID=switched major node name 


a ccmemeetaaelomiteatatemmnanmentonad 


PATH=USE 
specifies that one or more paths identified by the PID or GID operand are 
to be enabled (changed from unusable to usable), if they are not already 
enabled. 


PATH=NOUSE 
specifies that one or more paths identified by the PID or GID operand are 
to be disabled (changed from usable to unusable), if they are not already 
disabled. If the path is currently in use, PATH=NOUSE does not take 
effect until after the existing dial connection is broken. 


GID=n 
specifies the group identifier of the dial-out paths to be made usable or 
unusable. The group identifier is defined by the GID operand of the PATH 
statements in a switched major node definition. This value must be a 
decimal integer in the range O through 255. 


PID=n 
specifies the path identifier of the dial-out path to be made usable or 
unusable. This value must be a decimal integer in the range 0 through 255. 


The path identifier is defined by the PID operand of a PATH statement. 


This PATH statement must be associated with the physical unit specified in 
the ID operand of this command. (This PATH statement is in the switched 
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major node definition; do not confuse it with the PATH macro instructions 
used to define a path definition set.) 


ID=physical unit name | switched major node name 
specifies the name of the physical unit in a switched major node (if the PID 
operand is specified) or the name of the switched major node (if the GID 
operand is specified) for which dial-out path status is to be changed. 
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VARY REL 


The VARY REL command is used to release a previously-acquired NCP, or to 
release a physical unit attached by a nonswitched line to an NCP (whether or 
not the physical unit was previously acquired). 


The VARY REL command is usually applied to a previously-acquired NCP or 
physical unit as part of a backup and recovery procedure in a multiple-domain 
network. A physical unit can also be released as part of a switched network 
backup procedure in either a single- or multiple-domain network. The purpose 
of the VARY REL is to: 


1. Release ownership of NCP resources that are normally owned by another 
host (if the NCP was activated prior to being acquired). This kind of 
release requires that the Multisystem Networking Facility be installed. 


2. Release ownership of all resources within an NCP, including the NCP itself 
(if the NCP was acquired without having been previously activated). This 
kind of release requires that the Multisystem Networking Facility be 
installed. 


3. Release ownership of an individual physical unit and its logical units. 


Releasing resources within an NCP makes them unknown to ACF/VTAM until 
the NCP is reacquired; releasing a physical unit makes it unusable by the 
releasing host and makes its logical units unknown until the physical unit is 
reacquired. Releasing an NCP that had not been previously active (case 2 
above) also results in deactivation of the NCP. (In this case there is no 
functional difference between the VARY REL and VARY INACT commands.) 
See Chapter 3 for a description of possible backup and recovery procedures that 
use the VARY REL command. | 


As part of a switched network backup procedure, the VARY REL command 
can be entered for a physical unit that was not previously acquired. The 
purpose of the VARY REL command is to make the physical unit’s logical units 
unknown to ACF/VTAM so that a corresponding switched physical unit 
definition (representing the same physical device with a different physical unit 
name but with the same logical unit names) can be activated. See Chapter 3 
for a description of the switched network backup procedure. 


To release an NCP or a physical unit, enter: 


Operation Operands 

{VARY | V} NET,REL,ID=name 
[.CDLINK=ACT | INACT] 
[1] 

REL | 


specifies that the resource specified by the ID operand is to be released. 


ID=name 
specifies the name of the NCP or physical unit to be released. 
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‘CDLINK=ACT | INACT 


applies only to an NCP being released. It specifies whether any active 
cross-domain links and link stations are to remain active (in the NCP--not 
with respect to ACF/VTAM) after they are released. That is, the CDLINK 
operand specifies whether ACF/VTAM is to send deactivation commands 
to cross-domain links and link stations when the internal representations of 
these resources are deactivated as part of the VARY REL processing. 


For an NCP that was activated prior to being acquired, the NCP remains 
active after the VARY REL completes, so even though ACF/VTAM 
considers such links and link stations to be inactive, the NCP still considers 
them to be owned by ACF/VTAM. Therefore, specifying CDLINK=ACT 
in an environment of shared link and link station ownership might provide 


no benefits (because the shared ownership prevents traffic disruption on the 


link), but could cost the ability of some other host to become a shared 
owner (because the share count is one closer to its limit than it need be). 
See Chapter 2 for details of special considerations and cautions that might 
be applicable to deactivation of cross-domain links and link stations. 


For an NCP acquired without having been previously activated, this option 


is effective only on the first command (whether VARY INACT or VARY 


REL) applied to the NCP. Any subsequent CDLINK specifications are 
ignored. . 


CDLINK=ACT 
specifies that active cross-domain links and link stations are to remain 
active after they are released, so that sessions routing information 
through the NCP over such links can continue without disruption. 


CDLINK=INACT , 
specifies that cross-domain links and link stations within the scope of 
the release are to be deactivated as part of the NCP release processing. 
Any session traffic over such links might be disrupted (depending on 
whether such links and link stations are also owned by some other 
host). Refer to the description of links and link stations in Chapter 2 
for a discussion of how shared ownership affects the results of 
deactivating a link or link station. 


CDLINK=INACT is the default value. 


specifies immediate release. If I is not specified, normal release occurs. 
Normal release does not break existing sessions, but does prevent the 
establishment of new sessions with nodes within the scope of this command. 
If I is specified, sessions involving the resources being released are 
disrupted, but ACF/VTAM waits for application programs in session with 
these resources to formally end their sessions (that is, issue CLSDST) 
before completing the release processing. 


The I operand can be specified on a VARY REL command entered while a 
normal release is in progress. 


VARY TERM 


VARY TERM Command 


The VARY TERM command terminates a session or group of sessions. The 
cominand can identify one or several sessions for termination. It can identify: 


e <A single session by its session identifier 


e All of the sessions for which a specified logical unit is the primary session 
partner 


« All of the sessions for which a specified logical unit is the secondary session 
partner 


e All of the sessions between a specified pair of logical units having a 
specified primary/secondary relationship as session partners 


e All of the sessions for which a specified logical unit is a session partner 
(without regard to its primary or secondary status) 


e All of the sessions between a specified pair of logical units (without regard 
to their primary/secondary relationship as session partners) 


Operation Operands 


{VARY | V} NET,TERM, 
,LU1=LU name[,LU2=LU name] 
.PLU=primary LU name[,SLU=secondary LU name] 
81 D=session identifier 
sLU=secondary LU name[,PLU=primary LU name] 
[.NOTIFY=YES | NO] 
[,SCOPE=ACT | ALL | Q] 
| TYPE=COND | UNCOND | FORCE] 
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TERM 
specifies that a session or group of sessions is to be terminated. The TERM 
operand is a positional parameter and must immediately follow the NET 
operand. 


LU1=LU name 
specifies the name of a logical unit whose sessions are to be terminated. 


If specified with the L.U2 operand, only those sessions involving both 
specified logical units are to be terminated. 


LU2=LU name 
specifies the name of a logical unit whose sessions are to be terminated. 


If specified with the LU1 operand, only those sessions involving both 
specified logical units are to be terminated. 


PLU=primary LU name 


specifies the name of the logical unit whose sessions as the primary session 
partner are to be terminated. 


If specified with the SLU operand, only those sessions involving both 


specified logical units in the specified primary/secondary relationship are to 
be terminated. 
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SID=session identifier | 
specifies the ACF/VTAM session identifier for the particular session to be 
terminated. The session identifier supplied by ACF/VTAM in response to 
a DISPLAY ID=application program name,EVERY command (where the 
application program can be in this domain [application program minor node] 
or another domain [CDRSC minor node]}). | 


SLU=secondary LU name 
specifies the name of the logical unit whose scssions as the sccondary 
session partner are to be terminated. 


If specified with the PLU operand, only those sessions involving both 
specified logical units in the specified primary/secondary relationship are to 
be terminated. | 


NOTIFY=YES | NO 
specifies whether ACF/VTAM is to send a notification message to the 
operator when all affected sessions have ended. 


NOTIFY=YES | 
specifies that ACF/VTAM is to send a notification message to the 
operator when all affected sessions have ended. | 


NOTIFY=YES is the default value. 


NOTIFY=NO 
specifies that no message is to be written when all affected sessions 
have ended. 


SCOPE=ACT | ALL |Q 
specifies the scope of the command. 


SCOPE=ACT 
specifies that only active sessions are to be terminated. 


Note that the termination of an active session between a device-type 
logical unit and its controlling application program (if any) terminates 
the session but does not alter the basic controller relationship between 
them. The controller session can be reestablished with a VARY 
LOGON command or by a specific session request from the application 
program. Deactivation and reactivation of the logical unit (including 
error recovery procedures), or use of the logical unit by another 
application program, also results in the eventual re-establishment of the 
logical unit’s session with its controlling application program. 


SCOPE=ACT is the default value. 


SCOPE=ALL 
specifies that all sessions are to be terminated, whether active or 
queued. 


SCOPE=Q 
specifies that only queued sessions are to be terminated. 


If a queued session between a device-type logical unit and its controlling 
application program is terminated, the session remains queucd, but the 
automatic logon does not take place without some further action 
involving the session partners. See the discussion about re-establishing 
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the controller session under SCOPE=ACT for some of the actions that 
can trigger the automatic logon. 


TYPE=COND | UNCOND | FORCE 
specifies the type of session termination to be performed. 


TYPE=COND 
specifies conditional termination. 


If this command applies to active sessions, they are not disrupted, but 
application programs involved in such sessions are notified of the 
operator’s request for termination. 


If this command applies to queued sessions, they are terminated. 


TYPE=UNCOND 
specifies unconditional termination. 


If this command applies to active sessions, they are disrupted, 
application programs involved in such sessions are notified of the 
disruption, and ACF/VTAM waits for the application programs to 
formally end their sessions (that is, issue CLSDST) before completing 
the termination. 


If this command applies to queued sessions, they are terminated. 


For cross-domain sessions, if no SSCP-to-SSCP session exists, 
specifying TYPE=UNCOND is effectively the same as TYPE=FORCE. 


TYPE=UNCOND is the default value. 


TYPE=FORCE 
specifics forced termination. 


If this command applies to active sessions, they are disrupted, and 
application programs involved in such sessions are notified of the 
disruption; ACF/VTAM might have to wait (depending on how a given 
application program is coded; see ACF/VTAM Programming ) for the 
application programs to formally end their sessions (that is, issue 
CLSDST) before completing the termination. 


If this command applies to queued sessions, they are terminated. 


Note: Forced termination of a session involving a device-type logical 
unit causes the deactivation and reactivation of the logical unit. 
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Appendix A. Examples of DISPLAY Command Output 


This appendix contains sample output of ACF/VTAM DISPLAY commands. 
The samples are organized alphabetically by command. (This is the same order 
as they appear in Chapter 4.) For an explanation of the messages in the display 
output, refer to ACF/VTAM Messages and Codes. 


With one exception (D NET,BFRUSE), the samples shown apply to OS/VS 
systems and VSE systems. For each message in these display samples, the 
OS/VS message identifier is given first, followed by the equivalent VSE 
message identifier, and then the message text. For those messages that are for 
OS/VS only, the VSE column is blank, and for those messages that are for VSE 
only, the OS/VS column is blank. 


For the D NET,BFRUSE command, separate examples are given for OS/VS 
and VSE systems. 


Displaying All Application Programs (D NET,APPLS) 


d net,appls 


ISTO97I 5A97I DISPLAY ACCEPTED 
IST350I SDSOI VTAM DISPLAY - DOMAIN TY¥PE= AFPL MAJ NOCES/SNAMES 


ISTO89I SA89I VTAMSEG TYPE- APFL SEGMENT , ACTIV 

IST3600I S5D60I APPLICATIONS: 

ISTO&bOI SA8O0I THISHOST ACTIV ISTOLT=EP ACTIV ISTATAOG CONCT 
ISTOHOI SA80I ISTNOP ACTIV VTAMTERM NEVAC 

ISTO69T SA89L APPLIST TYEFi= APPEL SEGMENT , ACTIV 

IST360I 5D60IL APPLICAIIONS: 

ISTOBCI SA8OT VSPC CONCT DBLDCCICsS CONCT POWER CONCT 
ISTC#8OI 5A80L POAPPL66 CONCI POAP?iL1 CCNCT PCAFFL2 CCNCT 
ISTU8OI SA8O0I APPL1 CONCT TSO ACTIV TSOCOS1T ACTIV 
ISTObO0I 5A80I TSOCO92 TONCT TSO0003 CCNCT TSOCQ04 CONCT 
ISTGSCIT SABOI TSO0OCS CONCT TSO00G6 CONCT TSOO0CO7 CONCT 


IST314I SDI END 


Displaying ACF/VTAM Buffer Usage (D NET,BFRUSE) 


d net,bfruse (in OS/VS) 


ISTU97I DISPLAY ACCEPTED 
IST350I VTAM DISPLAY - DOMAIN TYPE= BUFFER PCCL DATA 


IST632I PUFF BUFF CURR CURR MAX MAX TIMcCS SXP/CONT LAP 
ISTo331 ID SIZE TOTAL AVAIL TOTAL USED EXP THRESHOLE INCR 
IST356I I000 09175 00064 GG054 OC064 00016 G000U COC0b6/----- 00C22 
IST3561 PPCO co0dcd CoLOO0 C0000 06000 00000 00009 N/a N/A 
IST356I LPOO 01916 90064 90063 00064 00065 60069 00022/----- 00604 
IST356I wWPOO 09152 091600 90142 GG6100 00018 00900 00001/----- 09025 
IsT356I NPOO C0000 OC0CO 9009 O0C00G 00009 0004 N/A N/A 
IST3560I LFCO 00120 090109 0190 09190 00909 05000 00033/----- 09032 
{ST356I CRPL 99116 G62005 00197 00200 06004 00064 00004/----- 00032 
IST356I UECB 00112 GC050 90059 0005¢ 00CG4H 60009 00017/----- 00034 
IST356I SFOG 90072 CC069 99651 09660 00009 O00y 00001/----- 09051 
IST3>d6I SPOO 909000 GOC90 00000 000900 00000 00000 N/A N/A 
IST356I apoac 99000 00009 000 aocod seectd GCOCY N/A N/A 


ISTU49I CSALIMIT = NOLIMIT ,CURRENT = G00309K ,MAXIGUM = ©90394K 
IST314I END 
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d net,bfruse (in VSE) 


SA97I DISPLAY ACCEPTEL a 
VPAM DISPLAY - DOMAIN TYPL= BUFFER ECCL DATA 
MAX TIMES 


BUFF. CURR 
SIZE TOTAL 


~~ 02988 JOCUEP 


02048 00140P 
09356 00010 
00175 00030 
90100 09025 
01016 00015 
09000 90060 
00152 00010 
00600 00000 
CO000 00COG 


CURR MAX 
AVAIL TOTAL 


USED EXP 


COQOUC1P N/A O0O00S5P N/A 
OCO31P N/A O0124P N/A 


00007 09010 00905 00900 C0001,/ 


BXP/CCNT 
THRESHOLD 


N/A 
N/A 


EXP 
INCR 
N/A 
N/A 

00005 


00021 00052 90045 00607 00063700025 G0011 


90025 00025 00906 900009 0C001/ 
00013 00015 00057 09000 29001/ 


00090 00000 99009 00000 


vC008 00010 00003 00600 G000T/ 


00000 00000 G0000 00000 


SpOCL 
53321 BUFF 
9G33I IDB 
Y9DOSo0oI VE 
SD0no6I VP 
5D50I SF 
SCSol LF 
OD50I SP 
5D50I LP 
SD560I AP 
5C50r WP 
5D50I PP 
5T5o0I NP 
SD50I UP 
SCWI END 


Displaying All CDRMs (D NET,CDRMS) 


d net.,cdrms 


ISTO97I SAQTI 
IST350I 5SD590I 
ISTOS9T SASSI 
IST462I SE82I 
IST482T SE82I 
IST4s621I SE82I 
TIST4s62T SE82I 
IST482I 5E&2I 
IST314I SDI4TI 


DISPLAY ACCEFTED 
VTAM DISPLAY - DOMAIN TYP2= 
CDRM SEGMENT 


CDRMSEG TYPZ= 
THISHOST ACTIV 
TWINHOST NEVAC 
CROSHOST ACTIV 
FARHOST ACTIV 
NETHOST NZYAC 
END 


Displaying All CDRSCs (D NET,CDRSCS) 
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d net,cdrscs 


ISTO97I SAQT7I 
IST350I 5D50I 
ISTOK9I SA89I 
IST443I 5E831 
IST483I SE83I 
IST463I SE831 
IST483I 52831 
IST483I 5E83I 
IST483I 5E831 
UST483T 5E83I 
IST483I 5z831 
IST483I 5E83I 
IST483I 55831 
IST483I SE&3I 
IST463I SE83I 


IST483I SE83I 


IST314I SD14I 


, SUBAREA 
, SUBARZA 
, SUBAREA 
, SUBAREA 
, SUBAREA 


ou wou ot 


CISPLAY ACCEFTED 


VTAM DISPLAY ~- DOMAIN TYPF= CROSS~-DOM. 
CDRSC SEGMENT 


CDRSCSEG TYPE= 


AISUBAS ACTIV »CDRB 
A2SUBA5 ACTIV eCDRE 
A3SUBA5 ACTIV «CDRS 
AYSUBAS ACTIV 7CDRM 
ASSUBA9 ACTIV eCDRM 
AG6SUBA9 ACTIV sCDRE 
A7SUBA13 ACTIV «CDRS 
A8SUBA13 ACTIV eCDRE 
RISUBA10 ACTIV eCDRM 
APPL8 ACTIV--S-- ,CDRKF 
APPL9 ACTIV--S-- ,CDRM 
@NETAPPLY ACTIV eCD&e 
APLAMDSEC ACTIV CDRS 


END 


0¢c000 00000 00000 00000 
099064 C0026 20026 90026 00000 06000 90C91/ 


CRCSS~DOE. 


RSRC MGR 


e ACTIV 


RESOURCES 


« ACTIV 


TWINHOST 
TWINHCST 
TWINHOST 
CROSHOST 
CROSHOST 
CRCSHOST 
FARHOST 
FaRHOST 
CROSHOST 
ftHISHOST 
THISHOST 
NETHOST 
NETHOST 


00018 


Displaying All Physical Units (D NET,CLSTRS) 


d net,clstrs 


ISTO97I SAQ7TI DISPLAY ACCEETED 
IST350I 5D50I VTIAM DISPLAY - DOMAIN TYPE= CLUSTERS/?HYS UNITS 
ISTO89I 5A89I ISTPUS TYPE= PU_T4/5 MAJ NCLE , ACTIV 
[STOS9I 5A89I NCPI TYPE= PU_T4/5 MAJ NODE , ACTIV 
ISTO89I 5A89I C3270A TYPE= PHYSICAL UNIT , ACTIV 
ISTO69X SA89I C3275A TYPE= PHYSICAL UNIT 7 ACTLY 
ISTOS9I SA89I NDSBSYOG TYPE= PHYSICAL UNIT 7 ACTIV 
ISTO89I 5A89I pul TYPE= PHYSICAL UNIT , ACTIV 
ISTO89I 5A89I CCJ13 TYPE= PHYSICAL UNIT , ACTIV 
ISTOS9I SAS9I PU13271R TYPE= PHYSICAL UNIT , ACTIV 
ISTOS9I 5A89I NTOPU1 TYPE= PHYSICAL UNIT , NEVAC----T 
ISTO69I SAS9I SWNDIAL TYPE= SW SNA MAJOR NODE , ACTIV 
ISTO89I SA89I SWITCHPU TYPE= PHYSICAL UNIT 4. CONCT 
ISTO69I SAB89I NZTIPU2 TYPE= PHYSICAL UNIT , CONCT 
ISTOS9I S5A89I NETIPU7 TYPE= PHYSICAL UNIT , Navac 
ISTOO9I SA89I NZTIPUI TYPE= PHYSICAL UNIT , CONCT 
ISTO89I 5A89I NETINTO TYPE= PHYSICAL UNIT , CONCT----T 
ISTOS9I SA89I LCL3790A TYPE= LCL SNA MAJ NODE , ACTIV 
ISTO89I SA89I PU11 TYPE= PHYSICAL UNIT , ACTIV , CUA=0B8 
IST314I SD14I END 


Displaying an Application Program (D NET,ID=appiname) 


d net,id=appll,e 


ISTO97I SAG7I DISPLAY ACCEPTED 

ISTO75I SA7S5I VTAM DISPLAY - NODE TYPE= APPL 

IST486I 5E86I NAME- APPL? , STATUS= ACTIV , DESIRED STATE=ACTIV 
IST654I 5G54I I/O TRACE= OFF ,BUFFER TRACE= OFF 

IST2714 JOBNAHE = TESTCASE STEPNAME = TESTCASE- - 

IST171I S5B71I ACTIVE SESSIONS = 0005 SESSION REQUESTS = 0001 

IST206I 5CO6I SzSSIONS: 

IST634I 5G34I NAME STATUS SESS ID SEND RECY VRN TP 
IST635I 5G35I APPL2 ACTIV-SEC  02010561D333340e 0000 0000 c 0 
IST635I 5G35I ABSUBA13 ACTIV-SEC 1A010000000C0002 0600 0000 oOo ¢ 
IST035I 5G35I Lut — ACTIV-SEC 02010561DE60BB30 0900 00900 c 0 
IST635I 5G35I L2SUBA10 ACTIV-SEC 02010561Z4BDFCkC 06000 0000 oO oC 
IST635I 5G35I ASSUBA9 ACTIV-PRI 1201000000000003 0000 0006 9 0 
IST635I 5G35I LU&SUBAIG QUE/C-SEC 620106219E07D9BD 

TST314I SD14I END 


Displaying a CDRM Major Node (D NET,ID=cdrmset) 


d net,id=cdrmseg,e 


IStcgy71 
ISTO75I 
IST4&6I 
IST4771I 
IST4¢R2l 
IST4E2T 
IST4sz.t 
IST482I 
IST482T 
IST3141 


5A9TI 
SAT5I 
5ESO6I 
5ET77I 
5E821 
SER2T 
55821 
5E82I 
5 E621 
5D14I 


DISPLAY ACCEPTED 

VTAM DISPLAY - NODE TYPE= CURK SEGMENT 
NAMc= CLORMSES ,STATUS= ACTIV 

CDRMS:. 

THISHOST ACTIV ,SUBAREA = 901 

TWINHOST NEVAC ,SUBAREA = 005 

CROSHOST ACTIV ,SUBAREA = 0069 

FARHOST ACTIV ,SUBAREA = 013 

NETHOST NEVAC ,SUBAREA = O46 

END 
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,DESIRED STATE=ACTIV 


Displaying a Host CDRM (D NET,ID=host cdrm) — 


Displaying an External 


d net,id=thishost,e 


ISTO97I 5A97I DISPLAY ACCEPTED 

ISTO75I 5A75I VTAM DISPLAY - NODE TYPE= CDRM 

IST486I SE86I NAME= THISHOST ,STATUS= ACTIV 7 LESIRED STATE= 
IST654I 5G54I I/O TRACE= OFF ,BUFFER TRACE= OFF 

IST4761I 5E76I CDRM TYPE = HCST , SUBAREA = 001 

IST388I SD&6I DYNAMIC CDRSC DEFINITION SUPPORT = YES 

IST171I 5B71I ACTIVE SESSIONS = 0002 SESSION REQUESTS = 0000 

IST477I SEV7I CDRMS: 

ISTo34I 5G34I° NAME STATUS SESS ID SEND RECV 
IST635I 5G35I CROSHOST ACTIV 9 
IST635I 5G35I FARHOST ACTIV 0 
IST314I 5DI4I END 


CDRM (D NET,ID=ext cdrm) 


d net,id=croshost,e 


ISTO97I SAY7I DISPLAY ACCEPTED : 

ISTO75I SA75I VTAM DISPLAY - NOCE TYPE= CDRM 
IST486I 5E86I NAME= CROSHOST ,STATUS= ACTIV 
IST654T 5G54I I/0 TRACE= OFF ,BUFFER TRACE= OFF 
IST476I SE76I CDRM TYPE = EXTERNAL ,SUBAREA = 009 
IST369I SD89I PREDEFINITION OF CDRSC = OPT 

IST478I 5E78I CORSCS: 
ISTO80I 5A80I AYSUBAY ACTIV A5SUBA9 ACTIV 
ISTO80I 5A80I L1SUBA10 ACTIV L2SUBA10 ACTIV 
IST314EF SDI4I END 


Displaying a CDRSC Major Node (D NET,ID=cdrsc set) 


d net,id=cdrscseg,e 


TSTO97I 5AY7I DISPLAY ACCEPTED 
ISTO75I SA75I VTAM DISPLAY - NODE TYPE= CDRSC SEGMENT 
IST486I SE86I NAME= CLORSCSEG ,STATUS= ACTIV 
TST478i SE7BI CPRSCS:  . . 
IST463I SE83I CDRSC1 ACTIV «CDRM = TWINHOST 
IST483I 5E83I A2SUBA5 ACTIV 7CDRM = TWINHOST 
IST483I SE83I A3SUBA5 ACTIV CDRH = TWINHOST 
IST483I 5E83I A4SUBAY ACTIV »CDRM = CROSHOST 
-IST483I SE83I ASSUBAS ACTIV »CDRM = CRCSHOST 
IST483I SE83I A6SUBA9 ACTIV CDR = CROSHOST 
IST483I SE83I ATVSUBA13 ACTIV »CDRM = FARHOST 
IST483I S5E83L A&SUBA13 ACTIV 7CDRM = FARHOST 
IST483I 5E&3I LISUBA10 ACTIV sCDRM = CROSHOST 
IST483I 5E83I L2ZSUBA10 ACTIV ~CDRM = CROSHOST 
IST483I SE83I R1SUBA10 ACTIV 7CDRH = CROSHOST 
IST483I S5E&83T L4SUBA14 ACTIV 7CDORM = FARHOST 
IST483I 5E83I LSSUBA14 ACTIV 7CDRM = FARHOST 
IST483I SE83I L6SUBA14 ACTIV 7CDRM = FARHOST 
IST463I SE83I APPL8 ACTIV--S-- ,CDRM = THISHOST 
IST4s3I SE83I APPLI ACTIV--S-- ,CDRM = THISHOST 
IST483I 5SE83I NETLU1 ACTIV 7CDRM = NeTHOST 
IST483I 5SE83I NETLU2 ACTIV 7CDRM = NETHOST 
IST463I S5E83I NETAPPL1 ACTIV eCDRM = NETHOST 
55831 ACTIV ~CDRM = NETHOST 
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IST4&3I 


NETAPPLY 


,CESIRED STATE=ACTIV 


A6SUBA9 ACTIV 
L3SUBA10 ACTIV 


»DESIRED STATE=ACTIV 


ACTIV 


VRN TP 


Displaying a Dynamically-Created CDRSC Major Node 


(D NET,ID=ISTCDRDY) 


d net,id=istcdrdy,e 


ISTO97I 
ISTO7SI 
IST486I 
IST4781I 
IST1721 
ISTIMWI 


SAQTI 
SA75I 
SE8 61 
5E78I 
5B721 
5D14I 


DISPLAY ACCEPTED 
VTAM DISPLAY - NODE TYPE= CDRSC SEGMENT 


NAME= ISTCDRDY 


CDORSCS: 


NO CDRSCS 


END 


, STATUS= ACTIV DESIRED STATE=ACTIV 


EXIST 


Displaying a CDRSC Minor Node (D NET,ID=cdrscname) 


d net,id=cdrscl,e 


ISTO97I 
ISTO75I 
IST486I 
IST479I 
IST1/1I 
IST206I1 
ISTi721 
IST3141 


5A97I 
SAT5I 
SE86I 
5SET9I 
5B7 11 
5C06I 
5B7 21 
SD4T 


DISPLAY ACCEFTED 

VTAM DISPLAY - NODE TYPE= CDRSC 

NAME= CDRSC1 7 oTATUS= ACTIV DESIRED STATE=ACTIV 
CDRM NAME = TWINHOST . 
ACTIVE SESSICNS = 0000 SESSION REQUESTS = 0000 

SESSIONS: 


NO SESSIONS 


END 


EXIST 


Displaying a PU__T4/5 (D NET,ID=pu4/5 name) 
Displaying the Host Physical Unit (D NET, ID=ISTPUS) 


d net,id=istpus,e 


ISTO97I 
ISTO75I 
IST4H6I 
IST484T 
ISTo541 
IST1701 
{STO80I 
IST3141 


SA9TI 
SA75I 
5E86I 
SE84I 
5G54I 
5B70I 
5A80I 
5D141I 


DISPLAY 


ACCEPTED 8 


VTAM DISPLAY - NODE TYPE= PU_T4/5 


NAME= 


ISTPUS 


, oTATUS= ACTIV DESIRED STATE=ACTIV 


SUBAREA = 001 


I/O TRACE= OFF 


LINES: 
OCF-L 
END 


Displaying an NCP (D NET,ID=ncpname) 


d net,id=ncploci,e 


ISTO97TI 
ISTO7SI 
IST4561I 
IST2471 
IST484T 
IST391I 
ISToS4I 
ISTO7V7I 
IST67/51I 
IST1701 
ISTOSOT 
ISTOSOT 
ISTO80I 
ISTOsOI 
ISTO80I 
IST3141I 


5A9TI 
SA7T5I 
5E86I 
SC47I 
SE84T 
5D9 11 
5G54T 
SATTI 
SG751 
SB7GI 
SA80I 
5A80I 
5A80I 
5A80T 
5A80I 
SD14IT 


DISPLAY 


BUFFER TRACE= OFF 


ACTIVG===] 


ACCEPTED 


VTAM DISPLAY - NODE TYPE= PU_T4/5 


NAME= NCPLOC1 


, STATUS= ACTIV «DESIRED STATE=ACTIV 


LOAD/DUMP PROCEDURE STATUS = RESET 
SUBAREA = 107 : 

ADJ LINK STATION = OCF-S LINE = OCF-L ,NODE =ISTPUS 
I/O TRACE= OFF ,BUFFER TRACE= CFF 

SIO= 60000538 CUA= OCF 

VR =..6',. Te = 2 

LINES: 

L1D33 ACTIV L1D56 ACTIV LSDLC1 ACTIV 
LSDLC2 ACTIV L13a ACTIV----E PAKUPLIN NEVAC 
L12B ACTIV----E L12C NEVAC L12D NEVAC 
LSDLC31 ACTIV L1A22 ACTIV----— NTCLNO1 NEVAC----T 
NTOLNO2 NEVAC----T NTOLNO3 NEVAC----T LSDLC4O ACTIV 
2ND 
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d net,id=ncpcrs3,e 


ISTO97I 5A97I DISPLAY ACCEPTED 

ISTO75I 5A75I VTAM DISPLAY - NODE TYPE= PU_T4/5 

IST486I 5E66I NAME= NCPCRS3 ,STATUS= ACTIV ,»DESIRED STATE=ACTIV 
IST247I SC47I LOAD/DUMP PRCCEDURE STATUS = RESET 

IST464I SE84I SUBAREA = 010 


IST391I 5D91E ADJ LINK STATION = LS13a LINE = L13A NODE = NCPLOC1 
IST654I 5G54I I/O TRACE= OFF ,BUFFER TRACE= OFF 

IST675I 5G75I WR = 0, TP = 9 

IST170I SBVOI LINES: 

ISTO80I 5SA80I L3D55 ACTIV CSDLC1 ACTIV L31A ACTIV----E 
ISTOG&0I 5A69I L32A ACTIV----E L32B ACTIV----E L35A ACTIV----E 


IST314I 5D14I END 


Displaying a Link (D NET,ID=link name) 
Displaying a Peripheral Link (SDLC) (a net,id=11d05,e) 


d net,id=11d05,e 


ISTG97I 5A97I DISPLAY ACCEPTED 

ISTO7V5I 5A75I VTAM DISPLAY - NODE TYPE= LIWE 

IST486I SE86I NAME= L1D05 /OTATUS= ACTIV DESIRED STATE=ACTIV 
ISTO67I 5A87I LINE TYPE= LEASED LINE GROUP= GROUPS 

IST134I SB34I MAJNOD= NCPLCC1 

IST655I 5G55I LINE TRACE STATUS = TRRES TG TRACE STATUS = TRRES 

ISTO84IT SA84I NETWORK NODES: . 

ISTO&8OT 5SA80I C3270A §# ACTIV CT3277A ACTIV CT3277B ACTIV 
ISTO8OI SA8CI CT3277C ACTIV C3275A ACTIV CT3275A ACTIV 


IST314I 5D14I END 


Displaying a Cross-Subarea Link (SDLC) 
d net,id=I1 2a,e 


ISTO97I 5A97I DISPLAY ACCEPTED 

ISTO75I 5A75I VWTAM DISPLAY - NODE TYPE= LINE 

IST486I SE86I NAME= L12A ,OTATUS= ACTIV DESIRED STATE=ACTIV 
ISTG87I SA87I LINE TYPE= LEASED LINE GROUP= GROUP21 

IST134I 5B34I MAJNOD= NCPLCC1 

IST6551I 5G55I LINE TRACE STATUS = TRRES TG TRACE STATUS = TRRES 

IST396I S5D96I LINENAME STATUS LNKSTA STATUS CTG GTG ADJNODE ADJSA 
IST397I SD97TI L12A ACTIV----E LS12A ACTIN=A-=s 1 1 NCPLR2 106 
IST314I 5D14XI END 


Displaying a Cross-Subarea Link (Channel) 
d net,id=Ocf-lLe 


ISTO97I SA97I DISFLAY ACCEPTZED 

ISTO75I 5A75I VTAM DISPLAY - NODE TYPe= LINE 
IST486I 5SE86I NAME= OCF-L ,OTATUS= ACTIV »DESIRED STATE=ACTIV 
ISTO87I 5SA87I LINE TYPE= LEASED LINE GROUP= ISTGROUP 

IST134I 5B34I MAJNOD= ISTPUS 

IST655I 5G55I LINE TRACE STATUS = TRRES TG TRACE STATUS = TRRES 

IST396I 5D96I LINENAME STATUS LNKSTA STATUS CTG GTG ADJNODE ADJSA 
IST397I 5D97I OCF-L ACTIV-~-=+1L. OCF=S ACTIV----I 1 1 NCPLOC1 107 
IST314I 5DI4I END 


oe ame 


we 
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Displaying a Link Station (D NET,ID=link station) 


Displaying a Channel Link Station 


d net,id=O0cf-s,e 


Istcgo71I 
ISTOVSI 
IST466I 
ISTO8 11 
IST396I 
IST397I1 
[ST314I 


5A97I 
5A751I 
5E86I 
5A8 1I 
5D96I 
5D971 
SD1I4I 


Displaying an SDLC Link Station 


DISELAY ACCEPTED 
VTAM DISPLAY - NODE TYPE= LINK STATION 


NAMZ= OCF-S ,STATUS= ACTIV eDESIRED STATZ=ACTIV 


LINE NAME= OCF-L » LINE GROCUP= ISTSKOUP , MAJNOD= IS TPUS 
LINENAMc STATUS LNKSTA STATUS CTG GTG ADJNODE ADJSA 
OCF-L ACTIV----I OCF-S ACTLY¥<=<--1 1 1 NCPLOC1 107 
END 


d net,id=Isi3a,e 


ISTO97I 
ISTO7SI 
IST4s86I 
ISTOS1I 
IST3961 
IST3971 
IST3 141 


SA9TI 
SA75I 
SES6I 
SA61I 
5D96I 
SD97I 
SDT4aT 


DISPLAY ACCEPTED | 
VTAM DISPLAY - NODE TYPE= LINK STATION 


Displaying a Logical Unit (D NET,ID=luname) 


d net,id=lul,e 


TSTO97I 
ISTO7SI 
IST486I 
ISTOS1I 
IST1351I 
ISTO0s2T 
ISTo5S4I 
ISTO75SI 
IST314I 


SA97I 
5A75I 
SEB 6I 
5A8 11 
5B351 
5 A8 2T 
5G54I 
5G75I 
5D14I 


NAME= LS13A e STATUS= ACTIV *»DESIRED STATE=ACTIV 
LIWE NAME= Li13A » LINE GROUP= CDGREO01 , MAJNOD= NCPLOC1 
LINENANE STATUS LNKSTA STATUS CTG GTG ADJNODE ADJSA 
L134 ACTIV----# LS1I3A ACTIV<-<-=5 1 1 NCPCRS3 C10 
END 

DISPLAY ACCEF&TED 

VTAM DISPLAY - NODE TYPE= LOGICAL UNIT 

NAME= LU1 eoTATUS= ACTIV DESIRED STATE=ACTIV 
LINE NAME= LINE1 , LINE GROUP= GROUPZO , MAJNOD= NCP1 
PHYSICAL UNIT= PU1 ; 

DEVTYPE= LU e ALLOC TO= APPL1 sCONTROLLING APPL= 

I/O TRAC&= OFF ,BUFFER TRACE= OFF 

VR = 0, TP = @ 

ERD 


Displaying a Physical Unit (D NET,ID=puname) 


d net,id=pul,e 


ISTO97I 
ISTO751 
IST486I 
ISTOS11I 
IST654I 
IST3551 
ISTO80T 
TSTusor 
ISTO80I 
IST314TI 


SA9TI 
5A75I 
SE861I 
5A8 11 
56541 
5D551 
5A80I 
5a80I 
5SA80I 
5Di4I 


DISPLAY ACCEPTED 
VIAM DISPLAY - NODE TYPE= PHYSICAL UNIT 


NAME= PU1 , STATUS= ACTIV sDESIRED STATE=ACTIV 
LINE NAME= LINE1 » LINE GROUP= GROUP2C0 , MAJNOD= NCP1 
I/O TRACE= OFF ,BUFFER TRACE= CFF 


LOGICAL UWITS: 
FAJEFFO1 ACTIV 
CTJIOLU3 ACTIV 
CTJ1TOLU4 ACTIV 
END 


CTJ10LU2 ACTIV 
SNUBULU2 WEVAC 


LU1 ACT/SS 
SNUBULU1 ACTIV 
CTJ10LU5 ACTIV 
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d net,id=swndial,e 


IST097I 
Isto75sr 
IST4&s6I 
ISTOGS4T 
ISTO89I 
ISTV8gI 
ISTOS9I 
ISTV8S9I 
ISTO89I 
ISTO89I 
ISTO89I 
ISTOS89I 
ISTO89I 
ISTO89T 
ISTO89I 
ISTOS9I 
ISTOI89I 
ISTO89I 
IST0891 
ISTO&9I 
IST3141 


SA9T7I 
5A75I 
5E86I 
5AB4T 
5A89I 
SA89TI 
SA89I 
5A69TI 
5A89I 
SAB9T 
5A89I 
5A89IT 
5A89I 
SA89T 
5A89I 
5A89TI 
SAB 9T 
5A89T 
5A89I 
5A89T 
5D14I 


DISPLAY 


NAME= SWNDIAL 
NETWORK NODES: 
SWITCHPU TYPE= 


PUTRTS1 TYPE= 
PUIRTS2 TYPE= 
PUTRTS3 TYPE= 
NETIPU2 TYPE= 
PU2ZRTS2 TYPE= 


SNUBULU1 TYPE= 
SNUBULU2 TYPE= 


NETIPU7 TYPE= 
PUT7LU1 TYPE= 
PU7LU3 TYPE= 
PU7LU4 TYPE= 
NETINTO TYPE= 
NTOLU3G TYPE= 
NET2ZNTO TIYPE= 
NTOLU31 TYPE= 
END 


Displaying a Local Non-SNA Major Node 
(D NET,ID=non-sna node) 


d net,id=1cl3270,e 


ISTO97TI 
ISTO75I 
IST486I 
IST355I1 
ISTU89T 
ISTOs9I 
ISTO89I 
ISTO89I 
IST3 141 


5A9TI 
SATSI 
5E86I 
5D551I 
5A89T 
5A89I 
5A89T 
5A89I 
5Di14I 


DISPLAY 
VTAM DISPLAY - 
NAME= LCL32706 
LOGICAL UNITS: 


L3270A TYPE= 
L3270B TYPE= 
L3270C TYPE= 
L3284A TYPE= 
END 


Displaying a Switched Major Node (D NET,ID=sw node) — 


ACCEPTED 
VTAM DISPLAY - NODE TYPE= SW SNA 


e STATUS= ACTIV 


PHYSICAL UNIT 
LOGICAL UNIT 


LOGICAL UNIT 


LOGICAL UNIT 
PHYSICAL UNIT 
LOGICAL UNIT 
LOGICAL UNIT 
LOGICAL UNIT 
PHYSICAL UNIT 
LOGICAL UNIT 
LOGICAL UNIT 
LOSICAL UNIT 
PHYSICAL UNIT 
LOGICAL UNIT 
PHYSICAL UNIT 
LOGICAL UNIT 


ACCEPTED 


MAJ NODE 


.». &£& & e & 8&8 8&8 &@ ®&® & & & &®& & & & 


NODE TYPE= LCL 3270 


, STATUS= ACTIV 


LOGICAL UNIT 
LOGICAL UNIT 
LOGICAL UNIT 
LOGICAL UNIT 


Displaying a Local SNA Major Node (D NET,ID=Local 


sna node) 
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d net,id=Icl3790a,e 


ISTOS7I 
ISTO75I 
IST436I 
ISTUS4UT 
ISTOs9t 
ISTOSII 
ISTU8S9II 
ISTO89I 
ISTVSITI 
IST3141 


5A9TI 
SAT5I 
SE8oIL 
SA84T 
5A89T 
SA89L 
5SA89T 
SA89I 
5As9T 
SDT4T 


DISPLAY ACCEPTED 
NODE TYPE= LCL SNA MAJ NODE 


VTAM DISPLAY - 
NAME= LCL3/90A 
NETWORK NODES: 


PU11 TYPE= 
LU112 TYPE= 
LU113 TYPE= 
LU114 TY2n= 
LU111 TYPsL= 
END 


,oTATUS= ACTIV 


PHYSICAL UNIT 
LOGICAL UNIT 
LOGICAL UNIT 
LOGICAL UNIT 
LOGICAL UNIT 


e s* 2% @a@ 


»DESIRED STATE=ACTIV 


CONCT 
CONCT 
CONCT 
COoxNCT 
CONCT 
CONCT 
RESET 
RESET 
NEVAC 
NoVAC 


~NEVAC 


NEVAC 


CONCT ====T 
CONC T=<==1 
CONCTS<<-1 
CONCT=—=-T 


MAJ NODE 


ACTIV 
NEVAC 
NEVAC 
NEVAC 


ACTIV 
ACTIV 
NEVAC 
NEVAC 
ACTIV 


»OESIRED STATE=ACTIV 


,CUA=3E0 
, CUA=3E1 
,CUA=3E2 
, CUA=3E5 


DESIRED STATE=ACTIV 


, CUA=0B8 


Displaying All Lines (D NET,LINES) 
d net,lines 


ISTV97I SAOTI DISPLAY ACCErTED 

IST350I 5sD50I VTAM DISPLAY - DOMAIN TYPS= LINES 
IST3541I 5D54I PU T4/5 MAJOR NODE = ISTPUS 
IST170I 5B70I LINES: 

ISTOtOLT 5SA80I OCF$-L ACT IVS eed 

IST354I SD5S4I PU T4/5 MAJOR NODE = NCPI1 

ISTI70I SB7OI LINES: 


ISTusCl 5SAB0I L£1A01 NEVAC LIA02 NEVAC L1D05 ACTIV 
ISTUSCI SABOI L1D34 ACTIV L1AG7 NZVAC L2A09 NEVAC 
ISTOSOT 5A80I L1D11 ACTIV DLMTAOQ1 NEVAC DLSSO02 NEVAC 
ISTCoOT SAB0T DLSSO4 NEVAC LLSSO5 NEVAC L1D55 ACTIV 
ISTOSCI 5SA80I £1D33 ACTIV L1D56 ACTIV LINE1 ACTIV 
ISTOKOI 5SA80I LSDLC2 ACTIV L13A ACTIV----~£ BAKUPLIN NEVAC 
ISTOSOI 5A80T L14a ACTIV----S BAKLIN2 ACTIV----E LI12A ACTIV----E 
ISTusCI 5A80I £128 ACTIVe=—-=3° LIZC NEVAC L12D NEVAC 
ISTO8SOI 5A80I L15A ACTIV----E L15B ACTIV----E L15C NEVAC 
ISTO8O0I 5ASOI LSDLC6 ACTIV LSDLC7 ACTIV LSDLC8& ACTIV 
ISTOSOI SA8O0I LINES ACTIV LSDLCT1 ACTIV LSELC9 ACTIV 
TSTO60I SA8OI LINEIC ACTIV LINE11 ACTIV LINE 12 ACTIV 
ISTOSOI SA89I LINE13 ACTIV LINE14 ACTIV LSDLC21 ACTIV 
[ISTOSOLI 5A80I LSDLC22 ACTIV LSDLC23 ACTIV LSDLC ACTIV 
ISTO80I 5A80I LSDLC32 acTiv LSDLC33 ACTIV LSDLC61 ACTIV 
ISTO&CGI 5SA80I LSDLC31 ACTIV L1IA2Z ACTIV----E NTOLNO1 NEVAC--~-T 
ISTO8O0I 5A80I NTOLNC2 NEVAC----T NTOLNO3 NEVAC----~f LSDLC4O ACTIV 
TSTO6KOI SA80I LSDLC41 ACTIV LSDLC50O ACTIV LSDLC51 ACT 


IST3I1W4I 5D14I END 


Displaying All Major Nodes (D NET,MAJNODES) 


d net,majnodes 


ISTO97I SA9TI DISPLAY ACCEPTED 
IST35CI 5D50I VTAM DISPLAY - DOMAIN TYP2= MAJOR NODES 


ISTO8¥9IT 5A89I VTAMSEG TYPE= APPL SEGMENT , ACTIV 
ISTV69I SA89I ISTPUS TYPE= PU_T4/5 MAJ NODE , ACTIV 
ISTO&9I 5A89I APPLIST TYPE= APPL SEGMENT , ACTIV 
ISTO89T 5SA89I RMDK3 TYP£= CDRM SEGMENT , ACTIV 
ISTOS9T S5A89T ISTCDRDY TYPr= CDRSC SEGMENT , ACTIV 
ISTOS9IT SAB9T) RSDK3 TYPE= CDRSC SEGMENT » ACTIV 
ISTO&9T S5A89I SWNDIAL TYPE= SW SNA MAJ NODE , ACTIV 
ISTO89T SA89I LCL3270 TYPE= LCL 3270 MAJ NCCE , ACTIV 
TSTU89T 5AK9IT LCL3790A TYPE= LCL SNA MAJ NODE , ACTIV 
ISTOS89I SA89T NCPLOC1 TYPE= PU_T4/5 MAJ NODE , ACTIV 
ISTO&9I SA89I NCPCRS3 TYPE= PU_T4/5 MAJ NODE , ACTIV 
ISTV89T 5AB9T NCPLR2Z TYPE= PU_T4U/5 MAJ NCDE , PAPUI 


IST314T SDI =END 
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Displaying the Storage of an NCP (D NET,NCPSTOR) 


d net,ncpstor,id=ncp1,addr=256,length=256 


SA97T 


ISTO97I DISPLAY ACCEPTED 

IST2Z44Y SC4U4T NCP STORAGE FCR ID = NCP1 

IST245I SC45I 000256 C940 A6969564 85994089 
IST245I 5C45I 090260 66408195 A8969585 40468993 9340909985 
IST245I 5C45I 000270 BIS6440A3 BBSBSA2ZOP 4O4O4N4D 4O4O40D4D 
IST245I SC45I 000256 4YOU04O4O 4040C940 86969584 85994089 
IST2451I 5cC45r 000260 86408195 A8969585 40468993 93409985 
IST245I SC4SI 000270 818440A3 8889A26F 40404080 4O40404D 
IST2451I 5C45I 000256 4O40404O 4040C940 A6969584 &5994089 
IST2451I 5C45I 000260 86408195 A8969565 40868993 93409985 
IST245I 5C45I 000270 818440A3 SBS9AZE6F 4OUO4O4D 40404040 
IST245I 5C45I 000256 GO4OKO4O 4O40C9I4O 46969584 85994089 
IST245I 5C45I 000260 86408195 A8969585 4CA68993 93409985 
ISTZ45I S5SC45I 000270 816440A3 BB889A2Z6F 4OUD4OKO 40404040 
TST245I 5C45I 000256 4YC4O404O 4OUOCI4D 236969584 85994089 
ISTZ45I 5C45I €00260 86408195 A8969585 40A68993 93409985 
IST2451% SC&5Ir 000270 B8I6E4U0A3 BBS9AZEF 4YO4O4OKO 490404040 
IST245I 5C45I 000340 OF6F6F6F 6FOF6OFOF OF6FOF6F 6F6F6F6F 
IST2Z45I 5C45I 000350 6FOF6F6F 6F6F 

IST314XY SDI4I END 

IST241I S5C4&1I NCPSTOR COMMAND COMPLET FOR ID = NCP? 


Displaying Nodes in a Pending State (D NET,PENDING) 


d net, pending 


ISTO97I SAY7I DISPLAY ACCEFTED 

IST350I 5D50L VTAM DISPLAY ~ DOMAIN TYPE= PENDING 
ISTOSOI SA80I LS12A PCTDiI LS12B PCTD1 
ISTOSOI SA8OI NCPCRS3 PCTI! 

ISTO6OI SA8GI NCPLR2 PAPU1 

IST314I 5Di4I END 


Displaying Information on Switched Paths (D NET,PATHS) 


d net,paths,id=switchpu 


ISTO97I 5A97I DISPLAY ACCEPTED 

ISTIW48I SB&4&I DIAL OUT PATH INFORMATION FOR PHYSICAL UNIT SWITCHPU 

ISTI49I SB49I LINE GRP TELE NO j LINE PIL GID CNT 

ISTIE8I SB6E8I GROUPE2 PUIPATH 1- 7890 001 007 003 AVA MAN 
IST168I SR68I GROUPE2 PUITPATH2-555-7890 002 002 003 AVA MAN 
IST168I 5B68I GROUP62 PU TPATH3- 1- 123-555-7890 CO4 CO4 010 NAV MAN 
IST374I 5DI4I Z2ND 
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Displaying the Current Routing Table (D NET,PATHTAB) 


d net,pathtab 


ISTQ97I SA97I DISPLAY ACCEPTED 
IST350I SD50I VTAM DISPLAY - DOMAIN TYPE= FATH TABLE CONTENTS 
IST516I SFI6I DESTSUB-ADJSUB-ER- ER STATUS-VR (5S) 


TST5171 SFI7I 0G1 001 0 ACTIV3 0 
IST5171I SFI7I 905 107 0 INOP 0 
IST5171 SPFI7I 009 107 0 MIGR 0 
ISt517I SFI7I 016 107 5 PDEFO 
IST5171 SF17I 010 106 3 INOP 3 
IST517I SF1I7I 010 197 3 INACT 6 
IST5171I SPF1I7I 010 107 0 ACTIV3 0 
IST517I SFI7EL 013 107 0 MIGR 0 
IST517I SF1I7I O14 106 5 INOP 3 
IST517I 5F17I 014 107 0 ACTIV3 0 
IST517I 5FI7I O48 106 4 INOP 4 
IST517I SPI7I 048 107 3 INOP 3 
IST517I 5F17I 048 106 2 INOP 2 
IST517I SFI7I 048 107 1 INOP 1 
IST5171I SFI7I 049 106 4 INOP 4 
IST5171I 5F17I 049 107 3 INOP 3 
IST517I SFI7I 049 106 2 INOP 2 
IST517I 5F17I 049 107 1 INOP 1 
IST517I SFI7I 106 107 5 PDEFO 
IST517I 5SF1I7I 106 106 5 INOP 3 
IST5171I SF17I 106 1907 3 INACT 6 
IST517I 5SFIU7I 106 107 0 INACT 0 
{IST517I SFI7I 107 107 7 PDEFO 
IST517I SFI 107 1607 6 PDEFO 
IST517I SFI7I 107 107 5 PDEFO 
ISTS17I SFI7I 107 107 4 PDEFC 
IST517I 5SFI7I 107 107 2 PDEFO 
IST5171I SPI7I 107 107 1 PDEFO 
IST517I SFI7I 1067 106 5 INO? 3 
IST517I 5SFI7I 107 107 3 ACTIV3 6 
ISTSt7I SFW7I 107 107 0 ACTIV3 0 
IST3146IT SDW4I END 

: @ @ 3 A] 

Displaying Routes to a Destination Subarea 

-(D NET,ROUTE) 
d net,route,destsub=1 
ISTO97I 5A97ZT DISELAY ACCEPTED 
IST535I 5F35E ROUTE DISPLAY 1 TO SA = 1 
IST536I 5F36I VR TP STATUS ER ADJSUB STATUS 
IST5371I 5F371 0 0 ACTILY 0 1 ACTIV3 
IST5371I 5P371 0 1 ACTIV 0 1 ACTIV3 
IST5371I SF371I 0 2 ACTIV 0 1 ACTIV3 


IST314I SDI4I END 
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Testing a Route to a Destination Subarea 
(D NET,ROUTE,TEST=YES) 


d net,route,destsub=10,test=yes 


ISTO97I SA97I DISPLAY ACCEPTED 


IST535I SF35I ROUTE DISPLAY & TO SA = 10 
IST536I 5F36I VR TP STATUS ER ADJSUB STATUS 
IST537I 5F37I 0 0 INACT 0 107 ACTIV3 
IST537I 5F37I 0 1 INACT 0 107 ACTIV3 
IST5371I 5F37I 0 2 INACT 0 107 ACTIV3 
IST5371I 5F371 1 UNDEF 
IST537I 5SF37I 2 UNIT EF 
IST537I 5F37I 6 0 INACT 3 107 INOP 
IST5371I SF37I 6 1 INACT 3 107 INOP 
IST5371I 5F37I 6 2 INACT 3 107 INOP 
IST5371I SF3I7I 4 UNDEF 
IST5371I 5F371 5 107 PDEFO 
IST5371I 5F37I 3 0 INACT 5 106 INOP 
IST5371I 5F37I 3 1 INACT 5 106 INOP 
IST5371I SF37I 3 INACT 5 106 INOP 
IST937I SF37I 6 UNDEF 
IST5371I dF3ITI 7 UNDEF 
IST314~I 5D1V4I END 
IST538I 5F38I ROUTE TEST 8 IN PROGRESS 
IST533I 5F332L ER 5 FAILED ROUTE TEST & FROM SA = 1 #%TO SA = 10 
IST534I SF34I ERLENGTH = °C ADJSUB = 106 TG = 1 
IST572I 5SF72I REJECTING SA = 1 ADJACENT TO SA = 106 VIA TG = 1 
IST573I 5F731 A REQUIRED TG IS INACTIVE, ER MASK = FFOQO 
IST533I SF33I ER 3 FAILED ROUT& TEST & FROM SA = 1 TO SA = TC 
IST534I 5F341 ERLENGTH = Q ADJSUE = 107 TG = 1 
IST572I SF72I REJ“CTING SA = 149 ADJACENT TO SA = 10 VIA TG = 1 
IST5731I 5F73I A REQUIRED TG IS INACTIVE, ER MASK = FFOO 
[IST5331I 5F33I ER O SUCCEELrEL IN ROUTS TEST 8 FROM SA = 1 TO SA = 10 
IST534I »oF34I ERLENGTH = 2 ADJSUE = 107 TG = 1 
IST533I SF33I ER 5 SUCCEEDED IN ROUTE TEST 8% FROM SA = 1 TO SA = 10 
IST234I SF34I ERLENGTH = 2 ADJSUB = 107 TG = 1 
@ a e LJ 

Displaying All Link Stations (D NET,STATIONS) 
d net,stations 
ISTO97I 5A9Y7I DISELAY ACCEPTED 
IST359I SD50XI VTAM DISPLAY - DOMAIN TYPE= STATIONS 
IST393I 5D93I PU T4H/5 MAJOR NODE: NAME = ISTPUS , UBARGA = O01 
IST396I 5D96I LINENAME STATUS LNKSTA STATUS CTG GTG ADJNOLE ADJSA 
IST397I 5D97I CCD-L AGCTIV4<+=—17 OCD=S RCTIV=s==1 1 1 NCPLR2 106 
IST397I 5D97I OCF-L ACTIV----I OQCF-S ACTIV=-=-1 1 1 NCPLOC1 107 
IST393I 5D93I PU T4/5 MAJOR NODE: NAME = NCPLOC1 ,SUBAREA = 107 
IST396I 5D960I LINENAME STATUS LNKSTA STATUS CTG GTG ADJNODE ADJSA 
IST397I SD97I L13A ACTIV----E LS13A ACL IN@=="E 1 1 NCPCRS3 010 
ISTI97I SDO97I LI14A ACTIV--~--E LS14A ACTIV=----£ 2 2 NCPFARG 0Q14 
IST397I 5D97I LI15A ACTIV="==E -LS15h ACTIV----a 1 1 NCPNETS O49 
IST393I 5D93I PU T4/75 MAJOR NODE: NAME = NCPLR2 , SUBAREA = 106 
IST396I SD96I LINENAMZ STATUS LNKSTA STATUS CTG GTG ADJNODE ADJSA 
IST397I 5SD97I L21A ACTIV----E LS21A PCTD1 1 1 107 
LST3971 SD97T. L23A ACTIV----E LS23A ACTIVe="=£ 3 3 NCPCRS3 010 


IST314I 5DW4I END 
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Displaying All Terminals (D NET,TERMS) 


d net,terms 


ISTO97I SAO7TI DISPLAY ACCEPTED 

IST350I 5SDSOI VTAM DISPLAY - DOMAIN TYPE= LOGICAL UNITS/TERMS 
IST354I SD5S4T PU T4H/75 MAJOR NODE = ISTPUS 

IST1461I 5SB4Y6I LINE NAME: OCF-L STATUS: ACTIV 

IST359I SD59I ATTACHMENT = LEASED 

IST354I 5D54I PU T4HYS MAJOR NODE = NCP1 


IST1I46I SB4Y6T LINE NAME: LILO5 STATUS: ACTIV 

IST359I 5D59I ATTACHMENT = LEASED 

ISTO69I SA89T C3270A TYPE= PHYSICAL UNIT , ACTIV 

IST355I 5D55I LOGICAL UNITS: 

ISTO6O0I SA80I cCT3277A ACTIV CT3277B ACTIV CT3277C ACTIV 
ISTOS9SI 5A89I C3275A TYPE= PHYSICAL UNIT » ACTIV 


IST355I SD55I LOGICAL UNITS: 

ISTO8OI SA80I CT3275A ACTIV 

IST146I SBY6I LINE NAME: DLATAO1 STATUS: NEVAC 
IST359I SD5S9I ATTACHMENT = SWITCHED 


IST146I SB46I LINE NAME: L1D55 STATUS: ACTIV 

IST359I 5D59I ATTACHMENT = LEASED 

ISTO89I 5A89T C3270D TYPE= PHYSICAL UNIT » ACTIV 

IST355I 5D55I LOGICAL UNITS: 

TSTO8SOLI SABOI CT3277D ACTIV CT32775 ACTIV CT3Z77F ACTIV 
£STOKSOI SA80I CT3277G NEVAC 

{STOS9IT 5A89E C3275D TYPE= PHYSICAL UNIT , ACTIV 


£ST355I 5D55I LOGICAL UNITS: 
ISTOG8OI SA80I CT3275D ACTIV 


ISTI46I SBY46I LINE NAME: LINE? STATUS: ACTIV 

IST359I 5D59I ATTACHMENT = LEASED 

TSTOS9IT SAB9T PUI TYPE= PHYSICAL UNIT , ACTIV 

IST355I 5D55Z LOGICAL UNITS: 

ISTO8O0I SA80L FAJEFFO1 ACTIV LU1 ACT/SS CTJIOLU2 ACTIV 
ISTG8OT 5A80I CTJIOLU3 ACTIV SRUBULU1 ACTIV  SNUEULUZ NEVAC 
ISTO6OT 5SA8O0L CTJ1IO0LU4 ACTIV CTJ1IGLU5 ACTIV 


IST146I 5B46I LINE NAME: LSELC2 STATUS: ACTIV 
IST359I 5D59X ATTACHMENT = LEASED 


ISTOS9I SAB9T CCJ13 TYPE= PHYSICAL UNIT , ACTIV 

TST355I 5D55I LOGICAL UNITS: 

ISTO80I 5SA80I FAJEFFO2 ACTIV CTJ13LU1 ACTIV CTJT3LU2 ACTIV 
ISTO80T 5A80L CTJ13LU3 ACTIV 

ISTU69I SA89I LAN5520 TYPE= PHYSICAL UNIT , NEVAC 


IST355I 5D55I LOGICAL UNITS: 
ISTO60I 5A80I LU15520 NEVAC 


ISTO89I SA89I ADRPU TYPE= PHYSICAL UNIT , NEVAC 

IST355I 5D55I LOGICAL UNITS: 

ISTC80I 5A60I ADDRLUOT NEVAC ADDRLUU2Z NEVAC ADDRLUO3 NEVAC 
ISTO80I SA8CI ADDRLUOY NEVAC ADDRLUOS NEVAC ADDRLUO6 NEVAC 
ISTIG6I SBY6T LINE NAME: L13A STATUS: ACTIV 


IST359I 5D59I ATTACHMENT = LEASED 

IST146I SB46I LINE NAME: BAKUPLIN STATUS: NEVAC 
IST359I 5D59I ATTACHMENT = LEASED 

IST146I SB46T LINE NAME: LSDLC6 STATUS: ACTIV 
IST359I 5D59I ATTACHMENT = LEASED 

ISTOK9I SASSI PUIRTSIA TYPE= PHYSICAL UNIT , ACTIV 
IST3I55I SD55I LOGICAL UNITS: 

ISTC80LT 5A80I RTSILU1i ACTIV 

IST353I 5D53I SWITCHED SNA MAJOR NODE: NAME = SWNDIAL 


ISTO89LT 5SA89T SWITCHPU TYPE= PHYSICAL UNIT . 4 CONCT 

IST355I 5SD55I LOGICAL UNITS: 

ISTOS6OIT SASO0I PUIRTS1 CONCT PUIRTS2 CONCT PUIRTS3 CONCT 
ISTOS9L SA89IT NETIPU2 TYPE= PHYSICAL UNIT « CONCT 

IST355I SD55I LOGICAL UNITS: 

ISTOSOI SA80I PU2RTS2 CONCT SNUBULU1 RESET SNUEULU2 RESET 
ISTO8S9I SA89LT NETINTO TYPE= PHYSICAL UNIT ; SOACTH+e-T 

IST355I 5D55I LOGICAL UNITS: 

ISTO8OI SA80I NTOLU30 CONCT---~T 

ISTO89I SA&9I NET2NTO TYPZ= PHYSICAL UNIT , CONCT=-=-T 

IST355I 5D55I LOGICAL UNITS: 

ISTO6OI 5A80%E NTOLU31 CCNCT----T 

IST351I 5D51I LOCAL 3270 MAJOR NODE: NAME = LCL3270 

ISTO869T 5SA89T L3270A TYPE= LOGICAL UNIT , ACTIV , CUA=3E0 
{ISTJ89T 5A69T L3270B TYPE= LOGICAL UNIT » NEVAC ,CUA=3E1 
ISTOS9T SA89T L3284A TYPE= LOGICAL UNIT , NeVac , CUA=325 
TST3521T 5D52~I LOCAL SNA MAJOR NODE: NAME = LCL3790A 

ISTO89ET 5A89I PUi1 TYPE= PHYSICAL UNIT , ACTIV , CUA=0B8 
IST355I 5D55I LOGICAL UNITS: 

ISTO80I SA80I LU112 ACTIY L0113 NEVAC LU 114 NEVAC 
ISTOs6GI 5A80I L111 ACTIV 


IST314I SDAV4T END 
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Displaying a TSO User ID (D NET,U) (MVS Only) 
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d net,u,id=user01,e 


ISTO097I 
ISTO75SI 
[ST4o6I 
IST5761I 
ISTz62I 
IST262I 
IST314I 


DISPLAY ACCEPTED 

VTA DISPLAY - NODE TYPE= TSC USERID 
NAME= USERO1 2 STATUS= ACTIV 

TSO TRACE = OFF 


APPLNANE = TSCOGOO1 , STATUS = ACTIV 
LUNAME = L3270A » STATUS = ACTIV 
END 


s¢DESIRED STATE=N/A 


Appendix B. Incompatibilities with ACF/VTAM Release 2 


ACF/VTAM Release 3 has the following operational incompatibilities with 
ACF/VTAM Release 2: 


« ACF/VTAM no longer supports an NCP deactivation hierarchy; that is, 
deactivation of an NCP does not imply deactivation of any other NCP. (In 
ACF/VTAM Release 2, deactivation of a ‘“‘local’’ NCP implied the 
deactivation of an attached “‘remote’’> NCP.) However, the deactivation of 
an NCP could disrupt one or more sessions with other NCPs, depending on 
the topology of the network, whether any links and link stations are 
automatically deactivated along with the NCP, and the particular routes 
carrying sessions. For disrupted SSCP sessions, if another virtual route is 
not available, session recovery remains pending until a route becomes 
available or until the operator deactivates the disrupted NCP. The operator 
is informed of both the original disruption and the pending route request. 


e The CDLINK operand of the VARY and HALT commands ts no longer 
unconditionally applied to the link between two NCPs channel-attached to 
the same host. It applies only if such a link is a true cross-domain link at 
the time the command containing the CDLINK operand is entered (that is, 
if one of the NCPs is not active to the host). 


° ACEF/VTAM attempts to leave active the same-domain cross-subarea links 
between two NCPs being concurrently deactivated. Therefore, all 
same-domain non-channel cross-subarea links are left active across an 
ACKE/VTAM halt. In the non-halt case, because two deactivation 
commands cannot be entered at exactly the same time, and because the 
exact timing of the execution of two deactivations cannot be predicted, 
different results might be obtained in the final status of same-domain links 
between two NCPs being concurrently deactivated. Specifically, a 
same-domain link could become a cross-domain link as one deactivation 
progresses. By the time the second deactivation is ready to process the link, 
il is processed according to the CDLINK specification. 


> ACKE/VTAM'’s recovery of NCPs in single- and multiple-failure situations 
might result in recoveries pending indefinitely if some or all of the 
attempted recovery actions fai] and no alternate routes are available. Such 
pending NCP recoveries can be purged by the operator by entering the 
VARY INACT command for the failing NCPs. 


« The REP operand on a VARY ACQ command for an inactive NCP 
attached through an active SDLC link station is not necessary in 
ACF/VTAM Release 3 and, if specified, is ignored. Note that REP was 
prohibited on a VARY ACQ command for an already-active NCP in 
ACF/VTAM Release 2, and this is continued in ACF/VTAM Release 3. 


¢ The RNAME operand of the VARY ACT command for a link station is not 
supported in ACF/VTAM Release 3 (except in certain migration situations, 
described in “Cross-Subarea Link Failures” in Chapter 3). Its use in 
nonmigration situations results in failure of the command. 
« ACEF/VTAM Release 2 initiated an immediate reload sequence for 
activation of an NCP through a “‘local-to-local” link (that is, activation of 


another domain's channel-attached NCP through the cross-domain SDLC 
link connecting the two domains). This was necessary to transmit the 
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required “remote” NCP load module to the communication controller, 
regardless of which end of the SDLC link was primary and which was | 
secondary. ACF/VTAM Release 3 no longer automatically performs such a 
reload sequence, because a “remote” load module in these circumstances is 
not a requirement with ACF/NCP/VS Release 3. If an operator desires a 
reload in the manner of ACF/VTAM Release 2 under these conditions, | 
“LOAD=YES” should be specified on the VARY ACT command. 


Deactivation of cross-subarea links is now more consistent with deactivation 
of other links in ACF/VTAM. Deactivation of a link now always results in 
the indirect deactivation of all of the link’s subordinate resources. For a 
cross-domain link, this means the subordinate link station. This was not 
done in ACF/VTAM Release 2 because there was no possibility of multiple 
connections to NCPs, and deactivation of the link station would have had to 
imply deactivation of the adjacent NCP. As a result, ACF/VTAM Release 
3 operators should exercise the same care with cross-subarea link 
deactivations as they use for cross-subarea link station deactivations. 


Forced reactivation (VARY INACT,R) of an NCP is changed to apply only 
to active NCPs and to perform reactivation only for the SSCP-to-NCP 
session. In ACF/VTAM Release 2, the single link station adjacent to the 
NCP was also reactivated as part of force reactivate processing. In 
ACF/VTAM Release 3, the command has no effect on the link stations in 
adjacent subarea nodes. A forced reactivation command can be entered for 
a link station that requires reactivation. 


Because forced reactivation of an NCP no longer affects adjacent link 
stations, the reactivation can no longer result in the dumping or reloading of 
the NCP’s communication controller. 


Forced reactivation for an NCP that was acquired as an inactive NCP 
attached through an active SDLC link station is changed to be consistent 
with general forced reactivation processing for an NCP. In ACF/VTAM 
Release 2, such a forced reactivation was processed as a forced deactivation 
(VARY INACT,F) and the NCP was deactivated, because this kind of 
acquired NCP could not be dumped or reloaded if it became necessary 
during the processing of the command. Because dumping and reloading is 
never a possibility during forced reactivation of an NCP in ACF/VTAM 
Release 3, forced reactivation is now the same for all NCPs, regardless of 
how they are activated or acquired. 


Messages IST284A (in OS/VS) and 5C84A (in VSE) are changed from 
“OPTION TO RECOVER” to “OPTION TO RELOAD” when a link 
station fails and AUTOIPL=YES is not specified in the definition of the 
adjacent NCP. Accordingly, the meaning of the operator reply ‘““NO”’ is 
changed. In ACF/VTAM Release 2, such a reply caused deactivation of 
the NCP (because no recovery was requested). In ACF/VTAM Release 3, 
this reply means that ACF/VTAM will not attempt to reload the NCP. 
ACF/VTAM tries to reactivate the affected adjacent link stations, assuming 
that the NCP has been or is being loaded by another host processor. 


Glossary of Terms and Abbreviations 


This glossary defines terms and abbreviations that are 
important in this book. It does not include terms 
previously established for IBM operating systems and 
IBM products used with ACF/VTAM. Additional 
terms can be found by referring to the index, to 
prerequisite and corequisite books, and to the JBM 
Data Processing Glossary, GC20-1699., 


This glossary includes definitions developed by the 
American National Standards Institute (ANSI) and the 
International Organization for Standardization (ISO). 
This material is reproduced from the American 
National Dictionary for Information Processing, 
copyright 1977 by the Computer and Business 
Equipment Manufacturers Association, copies of 
which may be purchased from the American National 
Standards Institute, 1430 Broadway, New York, New 
York 10018. 


A complete commentary taken from ANSI is identified 
by an asterisk that appears between the term and the 
beginning of the commentary; a definition taken from, 
ANSI is identified by an asterisk after the item number 
for that definition. 


The symbol /SO at the beginning of a definition 
indicates that it has been discussed and agreed upon at 
meetings of the International Organization for 
Standardization Technical Committee 
97/Subcommittee 1 (Data Processing), and has also 
been approved by ANSI. 


Reference Words Used in the Entries 
The following reference words are used in this 
glossary. 


Synonymous with. Appears in the commentary of a 
preferred term and identifies less desirable or less 
specific terms that have the same meaning. 


Synonym for. Appears in the commentary of a less 
desirable or less specific term and identifies the 
preferred term that has the same meaning. 


Contrast with. Refers to a term that has an 
opposed or substantively different meaning. 


See. Refers to multiple-word terms that have the 
same last word. 


See also. Refers to related terms that have similar 
(but not synonymous) meanings. 


A 
ACB. Access method control biock. 


ACB address space. In ACF/VTAM, the address space in which 
the ACB is opened. See associated address space and session 
address space. 


ACB-based macro instruction. In ACF/VTAM, a macro 
instruction whose parameters are specified by the user in an 
access method control block. | 


ACB name. (1) The name of an ACB macro instruction. (2) A 
name specified in the ACBNAME parameter of an APPL 
statement. Contrast with network name. 


Note: This name allows an ACF/VTAM application program 
that is used in more than one domain to specify the same 
application program identification (pointed to by the APPLID 
parameter of the program’s ACB statement) in each copy. 
ACF/VTAM knows the program by both its ACB name and its 
network name (the name of the APPL statement). Program users 
within the domain can request a session using the ACB name or 
the network name; program users in other domains must use the 
network name (which must be unique in the network). 


accept. In an ACF/VTAM application program, to accept a 
CINIT request from an SSCP to establish a session with a 
logical unit; the application program acts as the primary end of 
the session. Contrast with acquire (1). 


Note: The accept process causes a BIND request to be sent from 
the primary end of the session to the logical unit that will act as 
the secondary end of the session, requesting that the session be 
established and passing session parameiers. For example, ihe 
session-initiation request that originally caused the SSCP to send 
the CINIT request may have resulted from a logon by the 
terminal operator, from a macro instruction issued by an 
ACF/VTAM application program, or from an ACF/VTAM 
operator command. 


access method. A technique for moving data between main 
storage and input/output devices. 


access method control block (ACB). A control block that links an 
application program to VSAM or ACF/VTAM. 


accounting exit routine. In ACF/VTAM, an optional, 
installation exit routine that collects statistics about session 
initiation and termination. 


ACF. Advanced Communications Function. 


ACF/NCP. Advanced Communications Function for the 
Network Control Program. 


ACF/TCAM. Advanced Communications Function for the 
Telecommunications Access Method. 


ACF/VTAM. Advanced Communications Function for the 
Virtual Telecommunications Access Method. 


ACF/VTAM application program. A program that has opened an 


ACB to identify itself to ACF/VTAM and can now issue 
ACF/VTAM macro instructions. 
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ACF/VTAM definition. The process of defining the user 
application network to ACF/VTAM and modifying 
IBM-defined characteristics to suit the needs of the user. 


ACF/VTAM definition library. The operating system files or data 
sets that contain the definition statements and start options 
filed during ACF/VTAM definition. 


ACF/VTAME. Advanced Communications Function for the 
Virtual Telecommunications Access Method Entry. 


ACF/VTAM operator. A person or program authorized to issue 
ACF/VTAM operator commands. See domain operator, 
program operator, and network operator (2). 


ACF/VTAM operator command. A command used to monitor or 
control an ACF/VTAM domain. 


acquire. (1) In ACF/VTAM, the operation in which an 
authorized ACF/VTAM application program initiates and 
establishes a session with another logical unit; the application 
program acts as the primary end of the session. Note: The 
acquire process causes an Initiate request to be sent to the SSCP 
which causes the SSCP to return a CINIT request to the 
application program (the PLU); this in turn causes the PLU to 
send a BIND request to the SLU. Contrast with accept. (2) In 
relation to ACF/VTAM resource control, to take over 
resources (communication controllers or other physical units) 
that were formerly controlled by a data communication access 
method in another domain, or to assume control of resources 
that were controlled by this domain but released. Contrast with 
release. See also resource takeover 


active. In ACF/VTAM, pertaining to a major or minor node 
for which a VARY NET,ACT command has been issued. Also, 
a major or minor node in a list of major nodes to be activated 
when ACF/VTAM is started. Contrast with inactive. 


Note: For a major node, this makes the node and its minor 
nodes known to ACF/VTAM. Fer a minor node, this generally 
results in the execution of an SNA protocol to make the minor 
node usable by the network. For an LU minor node, this 
indicates that the ACF/VTAM operator has given permission for 
the LU to participate in an LU-LU session. 


adjacent nodes. In SNA, two nodes that are connected by one or 
more links with no intervening nodes. 


adjacent subareas. In ACF/VTAM, two subareas connected by 
one or more links with no intervening nodes. See also subarea. 


Advanced Communications Function (ACF). A group of IBM 
program products (principally ACF/TCAM, ACF/VTAM, 
ACE/VTAME, and ACF/NCP/VS) that use the concepts of 
Systems Network Architecture (SNA), including distribution of 
Function and resource sharing. 


Note: ACF/VTAME, ACF/NCP/VS, and the Multisystem 
Networking Facility of ACF/TCAM and ACF/VTAM allow the 
interconnection of two or more domains into one consolidated 
and coordinated multiple-domain network. 


Advanced Communications Function for the Network Control 
Program (ACF/NCP). A program product that provides 
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communication controller support for single-domain and 
multiple-domain data communication. . 


Advanced Communications Function for the Telecommunications 
Access Method (ACF/TCAM). A program product that provides 
single-domain data communication capability, and, optionally, 
multiple-domain capability. 


Advanced Communications Function for the Virtual 
Telecommunications Access Method (ACF/VTAM). A program 
product that provides single-domain data communication — 
capability and, optionally, multiple-domain capability. 


Advanced Communications Function for the Virtual _ 
Telecommunications Access Method Entry (ACF/VTAME). A 
program product that provides single-domain and 
multiple-domain data communication capability for 4300 
systems that may include communication adapters. 


any-mode. In ACF/VTAM: (1) The form of a RECEIVE 
request that obtains input from any one (unspecified) session. 
(2) The form of an accept request that completes the 
establishment of a session by accepting any one (unspecified) 
queued CINIT request. Contrast with specific-mode. See 
continue-any mode. See also accept. 


application program exit routine. In ACF/VTAM, a user-written 
exit routine that performs functions for a particular application 
program and is run as part of the application program. 
Examples are RPL exit routines, EXLST exit routines, and the 
TESTCB exit routine. Contrast with installation exit routine. 


application program identification. The symbolic name by which 
an application program is identified to ACF/VTAM. 


Note: /t is specified in the APPLID parameter of the ACB 
macro instruction. It corresponds to the ACBNAME parameter in 
the APPL statement or, if ACBNAME is defaulted, to the name 
of the APPL statement. 


application program major node. In ACF/VTAM, a meinber or 
book of the ACF/VTAM definition library that contains one or 
more APPL statements, each representing an application 
program. 


associated address space. In ACF/VTAM, the address space in 
which RPL-based requests are issued that specify an ACB 
opened in another address space. 


asynchronous operation. [n ACF/VTAM, an operation, such as a 
request for session establishment or data transfer, in which the 
application program ts allowed to continue execution while 
ACF/VTAM performs the operation. ACF/VTAM informs 

the program after the operation is completed. 


asynchronous request. [In ACF/VTAM, a request for an 
asynchronous operation, 


authorization exit routine. In ACF/VTAM, an optional, | 
installation exit routine that approves or disapproves requests. 
for session initiation. | . eee ee 


authorized path. In ACF/VTAM for MVS, a facility that enables 
an application program to specify that a data transfer or related 
operation be carried out in a privileged, and more efficient 
manner. 


automatic activation. In ACF/VTAM, the activation of links and 
link stations in adjacent subarea nodes as a result of channel 
device name or RNAME specifications related to an activation 
command naming a subarea node. 


automatic deactivation. In ACF/VTAM, the deactivation of 
links and link stations in adjacent subarea nodes as a result of a 
deactivation request naming a subarea node. 


Note: Automatic deactivation occurs only for automatically 
activated links and link stations that have not also been directly 
or indirectly activated. 


automatic logon. A process by which ACF/VTAM creates a 
session-initiation request (logon) for a session between a 
secondary logical unit (other than a secondary application 
program) and a designated primary logical unit whenever the 
secondary logical unit is not.in session with, or queued for a 
session with, another primary logical unit. See also controlling 
application program. 


Note: Specifications for the automatic logon can be made when 
the secondary logical unit is defined or can be made via the 
VARY NET,LOGON command. 


auxiliary network address. In ACF/VTAM, any network address, 
except the main network address, assigned to an LU capable of 
having parallel sessions. Contrast with main network address. 


available. In ACF/VTAM, pertaining to a logical unit that is 
active, connected, enabled, and not at its session limit. 


basic information unit (BIU). In SNA, the unit of data and 
control information that is passed between half-sessions. It 
consists of a request/response header (RH) followed by a 
request/ response unit (RU). 


basic mode. In ACF/VTAM Release 1 and in VTAM, a mode of 
data transfer in which the application program can 
communicate with non-SNA terminals without using SNA 
protocols. Contrast with record mode. 


basic transmission unit (BTU). (1) In SNA, the unit of data and 
control information passed between path control components. 
A BTU can consist of one or more path information units. 
(PTUs). See also blocking of PIUs. (2) In the network control 
program, the unit of exchange between the host. processor and 
the communication controller. It consists-of control 
information and may also include data. The control - 
information consists of a basic transmission header (BTH) and 
a basic device unit (BDU). All data transferred between the 
processing unit and the communication controller is preceded 
by a BTH. 


begia bracket. In SNA, the value (binary 1) of the begin-bracket 
indicator in the request header (RH) of the first: request in the 


first chain of a bracket; the value denotes the start of a bracket. 
Contrast with end bracket. See also bracket. 


bidder. In SNA, the LU-LU half-session defined at session 
activation as having to request and receive permission from the 
other LU-LU half-session to begin a bracket. Contrast with 
first speaker. See also bracket protocol. 


BIND. A request to activate a session between two logical units. 
BIU. Basic information unit. 


BIU segment. In SNA, the portion of a basic information unit 
(BIU) that is contained within a path informatin unit (PIU). It 
consists of either a request/response header (RH) followed by 
all or a portion of a request/response unit (RU), or only a 
portion of an RU. 


blocking of PIUs. In SNA, an optional function of path control 
that combines multiple path information units (PIUs) into a 
single basic transmission unit (BTU). 


Note: When blocking is not done, a BTU consists of one PIU. 


boundary function. In SNA, (1) A capability of a subarea node to 
provide protocol support for adjacent peripheral nodes, such 

as: (a) transforming network addresses to local addresses, and 
vice versa; (b) performing session sequence numbering for 
low-function peripheral nodes; and (c) providing session-level 
pacing support. See also path control network, network 
addressable unit. (2) The component that provides these 
capabilities. 


boundary node. A network node that performs boundary 
functions. See also boundary function. 


bracket. In SNA, one or more chains of request units (RUs) and 
their responses that are exchanged between the two LU-LU 
half-sessions and that represent a transaction between them. A 
bracket must be completed before another bracket can be 
started. Examples of brackets are data base inquiries/replies, 
update transactions, and remote job entry output sequences to 
work stations. 


bracket protocol. In SNA, a data flow control protocol in which 
exchanges between the two LU-LU half-sessions are achieved 
through the use of brackets, with one LU designated at session 
activation as the first speaker and the other as the bidder. The 
bracket protocol involves bracket initiation and termination 
rules. See also bidder, first speaker. 


BTU. Basic transmission unit. 


cancel closedown. A closedown in which ACF/VTAM is 
abnormally terminated either because of an unexpected 
situation or as the result of an operator command. 


CDRM Cross-domain resource manager. 


chain. See RU. chain. 
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change-direction protocol. In SNA, a data flow control protocol 
in which the sending logical unit (LU) stops sending 
normal-flow requests, signals this fact to the receiving LU using 
the change-direction indicator (in the request header of the last 
request of the last chain), and prepares to receive requests. 


chamnel-attached. (1) Pertaining to the attachment of devices 
directly by I/O channels to a computer. Contrast with 
link-attached. (2) Pertaining to devices that are attached toa 
controlling unit by cables, rather than by communication lines. 


channel device name. The symbolic name by which a 
channel-attached device is identified to the host operating 
— system: sometimes also known as a channel unit address. 


character-coded. In ACF/VTAM, pertaining to commands 
(such as LOGON or LOGOFF) entered by an end user and sent 
‘by a logical unit in character form. The character-coded 
command must be in the syntax defined in the user’s 
unformatted system services definition table. Synonym for 
unformatted. Contrast with field-formatted. 


CID. Communication identifier. 


CINIT. A network services request sent from an SSCP to an LU 
requesting that LU to establish a session with another LU and 
to act as the primary end of the session. 


ciphertext. Synonym for encipkered data. 


class of service (COS). In SNA, a designation of the path control 
network characteristics, such as path security, transmission 
priority, and bandwidth, that apply to a particular session. The 
end user designates class of service at session initiation by using 
a symbolic name that is mapped into a list of virtual routes, any 
one of which can be selected for the session to provide the 
requested level of service. 


Cleanup. A network services request, sent by an SSCP to an LU, 
that causes a particular LU-LU session with that LU to be ended 
immediately (without requiring the participation of either the 
other LU or its SSCP). 


clear data. Data that is not enciphered. Synonymous with 
Plaintext. 


clear session. A session in which only clear data is transmitted 
or received. Contrast with cryptographic session. 


closedown. The deactivation of a device, program, or system. 


See cancel closedown, orderly closedown, and quick closedown. 


cluster controller. A device that can control the input/output 
operations of more than one device connected to it. A cluster 
controller may be controlled by a program stored and executed 
in the unit; for example, the IBM 3601 Finance Communication 
Controller. Or it may be controlled entirely by hardware; for 
example, the IBM 3272 Contral Unit. 


CNM. Communication network management. 
command. (1) A request from a terminal for the performance of 


an operation or the execution of a particular program. (2) In 
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SNA, any field set in the transmission header (TH), request 
header (RH), and sometimes portions of a request unit, that 
indicates an action or that begins a protocol; for example: (a) 
Bind Session (session-control request unit), a command that 
activates an LU-LU session, (b) the change-direction indicator 
in the RH of the last RU of a chain, (c) the virtual route reset 
window indicator in a FID4 transmission header. (3) See also 
ACF/VTAM operator command. 


communication adapter. An optional hardware feature, available 
on certain processors, that permits communication lines to be 
attached to the processors. 


communication common carrier. In the USA, a 
government-regulated private company that furnishes the 
general public with telecommunication service facilities; for 
example, a telephone or telegraph company. 


communication control character. *(ISO) Synonym for 
transmission control character. 


communication controller. A type of communication control unit 
whose operations are controlled by one or more programs 
stored and executed in the unit. Examples are the IBM 3704 
and 3705 Communications Controllers. 


communication control unit. A communication device that 
controls the transmission of data over lines in a network. 
Communication control units include transmission control units 
(such as the 2702 Transmission Control Unit) and 
communication controllers (such as the 3705 Communications 
Controller). 


communication identifier (CID). In ACF/VTAM, a key for 
locating the control blocks that represent a session. The key is 
created during the session-establishment procedure and deleted 
when the session ends. 


communication line. Any physical link, such as a wire or a 
telephone circuit, that connects one or more remote terminals 
to a communication control unit, or connects one 
communication control unit with another. Contrast with link. 


communication macro instructions. In ACF/VTAM, the set of 


RPL-based macro instructions used to communicate within a 


session. 


communication management configuration. A technique for 
configuring a network that allows for the consolidation of many 
network management functions for the entire network in a 
single host processor. 


. communication network management (CNM) application program. 


An ACF/VTAM application program that is authorized to issue 
formatted management services request units containing 
physical-unit-related requests and to receive formatted 
management services request units containing information from 
physical units. 


configuration restart. In ACF/VTAM, the recovery facility that 
can be used after a failure or deactivation of a major node, 
ACF/VTAM, or the host processor to restore the domain to its 
status at the time of the failure or deactivation. 


configuration services. In SNA, one of the types of network 
services in the system services control point (SSCP) and in the 
physical unit (PU); configuration services activate, deactivate, 
and maintain the status of physical units, links, and link 
stations. Configuration services also shut down and restart 
network elements and modify path-control routing tables and 
address-transformation tables. See also maintenance services, 
management services, network services, session services, and 
system services control point. 


connected. In ACF/VTAM, pertaining to a PU or LU that has 
an active physical path to the host processor containing the 
SSCP that controls the PU or LU. 


connection. Synonym for physical connection. 


connection point manager In SNA, a component of the 
transmission control layer that: (1) performs session-level 
pacing of normal!l-flow requests, (2) checks sequence numbers of 
received request units, (3) verifies that request units do not 
exceed the maximum permissible size, (4) routes incoming 
request units to their destinations within the half-session, and 
(5S) enciphers and deciphers FMD request units when 
cryptography is selected. The connection point manager 
coordinates the norma! and expedited flows for one 
half-session. 


Note: The sending connection point manager within a 


half-session builds the request/response header (RH) for outgoing 


request/response units, and the receiving connection point 
manager interprets the request/response headers that precede 
incoming request/response units. 


continue-any mode. In ACF/VTAM, a state into which a session 


is placed that allows its input to satisfy a RECEIVE request 
issued in any-mode. While this state exists, input on the session 
can also satisfy RECEIVE requests issued in specific-mode. 
Contrast with continue-specific mode. 


continue-specific mode. In ACF/VTAM, a state into which a 
session is placed that allows its input to satisfy only RECEIVE 
requests issued in specific-mode. 


controlling application program. In ACF/VTAM, an application 
program with which a logical unit (other than a secondary 
application program) is automatically put in session whenever 
the logical unit is available. See also automatic logon. 


converted command. An intermediate form of a character-coded 
command produced by ACF/VTAM through use of an 
unformatted system services definition table. The format of a 
converted command is fixed; the unformatted system services 
definition table must be constructed in such a manner that the 
character-coded command (as entered by a logical unit) is 
converted into the predefined, converted command format. 

See also unformatted. 


COS. Class of service. 


cross-domain. Pertaining to control or resources involving more 
than one domain. 


cross-domain keys. In SNA, a pair of cryptographic keys used by 
a system services control point (SSCP) to encipher the session 


cryptography key that is sent to another SSCP and to decipher 
the session cryptography key that is received from the other 
SSCP during initiation of cross-domain LU-LU sessions that use 
session-level cryptography. 


cross-domain link. A link physically connecting two domains. 


cross-domain LU-LU session. In SNA, a session between logical 
units (LUs) in different domains. Contrast with same-domain 
LU-LU session. 


cross-domain resource. A resource owned by a CDRM in 
another domain but known by the CDRM in this domain by 
network name and associated cross-domain resource manager. 


cross-domain resource manager (CDRM). In ACF/VTAM, the 
portion of the system services control point (SSCP) that 
controls initiation and termination of cross-domain Sessions. 


cross keys. Synonym for cross-domain keys. 


cross-Subarea. In SNA, pertaining to control or resources 
involving more than one subarea node. 


cross-subarea link. A link between two adjacent subarea nodes. 
CRY. Cryptography Verification. 


cryptographic. Pertaining to the transformation of data to 
conceal its meaning. 


cryptographic algorithm. A set of rules that specify the 
mathematical steps required to encipher and decipher data. 


cryptographic key. A 64-bit value (containing 56 independent 
bits and 8 parity bits) that functions with the Data Encryption 
Standard (DES) algorithm in determining the output of the 
DES algorithm. See cross-domain keys, session cryptography 
key, host master key, and secondary logical unit key. 


cryptographic session. A session in which data may be 

enciphered before it is transmitted and deciphered after it is 
received. Contrast with clear session. See required cryptographic 
session and Selective cryptographic session. 


cryptographic session key. In SNA, deprecated term for session 
cryptography key. 


Cryptography Verification (CRV) request. A request unit sent by 
the primary logical unit (PLU) to the secondary logical unit 
(SLU) as part of cryptographic session establishment, to allow 
the SLU to verify that the PLU is using the correct 
cryptographic session key. 


D 
data communication. *The transmission and reception of data. 


data encrypting key. A cryptographic key used to encipher and 
decipher data transmitted in a cryptographic session. Contrast 
with key encrypting key. See session cryptography key. 
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Data Encryption Standard (DES) algorithm. A cryptographic 
algorithm designed to encipher and decipher data using a 64-bit 
cryptographic key, as specified in the Federal Information 
Processing Standard Publication 46, January 15, 1977. 


data flow control (DFC). In SNA, a request/ response unit (RU) 
category used for requests and responses cxchanged between 


the data flow control layer in one half-session and the data flow | 


control layer in the session partner. 


data flow control (DFC) layer. In SNA, the layer within a 
half-session that (1) controls whether the half-session can send, 
receive, or concurrently send and receive request units (RUs); 
(2) groups related RUs into RU chains; (3) delimits transactions 
via the bracket protocol: (4) controls the interlocking of 
requests and responses in accordance with control modes 
specified at session activation; (5) generates sequence numbers; 
and (6) correlates requests and responses. 


data flow control protocol. The sequencing rules for requests and 
responses by which network addressable units in a session 
coordinate and control data transfer and other operations. For 
example, see bracker protecol. 


data link. In SNA, synonym for link. 


data link control (DLC) layer. In SNA, the layer that consists of 
the link stations that schedule data transfer over a link between 
two nodes and perform error control for the link. Examples of 
data link control are SDLC for serial-by-bit link connection and 
data link contro! for the System/370 channel. 


data link control protocol. A set of rules used by two nodes ona 
data link to accomplish an orderly exchange of information. 
Synonyrnous with line control. 


data traffic reset state. The state usually entered after Bind 
Session, if Cryptography Verification is used, and after Clear, 
but prior to Start Data Tratfic. While a session is in this state, 
requests and responses for data and data flow control cannot be 
sent. Only certaim session control requests can be sent. 


decipher. ‘To convert enciphered data into clear data. Contrast 
with encipher. 


definite response. In SNA, a value in the 
form-of-response-requested field of the request header. The 
value directs the receiver of the request to return a response 
unconditionally, whether positive or negative, to that request. 
Contrast with exception response, no response. 


definition statement. The means of describing an element of the 
network. 


delayed-request mode. In SNA, an operational mode in which 
the sender may continue sending request units on the normal 
flow after sending a definite-response request chain on that 
flow, without waiting to receive the response to that chain. 
Contrast with immediate-request mode. 


delayed-response mode. In SNA, an operational mode in which 
the receiver of normal-flow request units can return responses 
to the sender 1n a sequence different from that in which the 
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corresponding request units were sent. Contrast with 
immediate-response inode. 


Note: An exception is the response to the DFC request CHASE: 
all responses to normal-flaw request units received before 
CHASE must be sent befere the response to CHASE is sent. 


DES. Data Encryption Standard. 


device control character. (ISO) A control character used for the 
control of ancillary devices associated with a data processing 
system or data communication system, for example, for 
switching such devices on or off. 


device-type logical unit. In ACF/VTAM, a logical unit that has a 
session limit of one and can act only as the secondary end of a 
session. It 1s typically an SNA terminal (such as a logical unit 
for a 3270 terminal or a logical unit for a 3790 application 
program). See also peripheral node. 


DFC. Data Flow control. 


DFSYN response. In ACF/VTAM. a normal!-flow response that 
is treated as a normal-flow request so that it may be received in 
order with normal-flow requests. 


direct activation. In ACF/VTAM, the activation of a resource as 
a result of an activation command specifically naming the 
resource. 


direct deactivation. In ACF/VTAM, the deactivation of a 
resource as 4 result of a deactivation command specifically 
naming the resource. 


disabled. In ACF/VTAM, pertaining to an LU that has 
indicated to its SSCP that it is temporarily not ready to 
establish LU-LU sessions. An Initiate request for a session with 
a disabled LU can specify that the session be queued by the 
SSCP until the LU becomes enabled. The LU can separately 
indicate whether this applies to its ability to act asa PLU or an 
SLU. See also enabled and inhibited. | 


disconnection. The termination of a physical connection. 
DLC. Data link control. 


domain. In SNA, a system services control point (SSCP) and the 
physical units (PUs), logical units (LUs), links, link stations, 
and all the associated resources that the SSCP has the ability to 
control by means of activation requests and deactivation 
requests. 


domain operator. In a muitiple-domain nctwork, the person or 
program that controls the operation of the resources controlled 
by one system services control point. Contrast with network 
operator (2). 


DRDS. Dynamic reconfiguration data set. 


duplex. *(1) (ISO) In data communication, pertaining to a 
simultaneous two-way independent transmission in both 
directions. Synonymous with full duplex. (2) Contrast with 
half duplex. 


dynamic reconfiguration. In ACF/VTAM, the process of 
changing the network configuration (peripheral PUs and LUs) 
associated with a boundary node, without regenerating the 
boundary node’s complete configuration tables. 


dynamic reconfiguration data set (DRDS). In ACF/VTAM, a data 
set used for storing definition data that can be applied to a 
generated communication controller configuration at the 
operator’s request. See also dynamic reconfiguration. 


E 


echo check. *A method of checking the accuracy of 
transmission of data in which the received data are returned to 
the sending end for comparison with the original data. 


element. (1) A field in the network address. (2) The particular 
resource within a subarea identified by the element field. See 
also subarea. 


element address. In SNA, a value in the element address field of 
the network address identifying a specific resource within a 
subarea. See subarea address. 


emulation mode. The function of a network control program 
that enables it to perform activities equivalent to those 
performed by a transmission control unit. Contrast with 
network control mode. 


enabled. In ACF/VTAM, pertaining to an LU that has 
indicated to its SSCP that it is now ready to establish LU-LU 
sessions. The LU can separately indicate whether this appiies 
to its ability to act asa PLU or an SLU. See also disabled and 
inhibited. 


encipher. (1) To scramble data or convert it, prior to 
transmission, to a secret code that masks the meaning of the 
data to any unauthorized recipient. (2) In ACF/VTAM, to 
convert clear data into enciphered data. Contrast with decipher. 


enciphered data. Data that 1s intended to be illegible to all 
except those who legitimately possess the means to reproduce 
the clear data. Synonymous with ciphertext. 


end bracket. In SNA, the value (binary 1) of the end bracket 
indicator in the request header (RH) of the first request of the 
last chain of a bracket; the value denotes the end of the bracket. 
Contrast with begin bracket. See also bracket. 


end user. In SNA, the ultimate source or destination of 
application data flowing through an SNA network. An end user 
may be an application program or a terminal operator. 


ER. Explicit route. 


exception request (EXR). In SNA, a request that replaces 
another message unit in which an error bas been detected. 


Note: The exception request contains a 4-byte sense field that 
identifies the error in the original message unit and, except for 
some path errors, is sent to the destination of the original 
message unit; if possible, the sense data is returned in a negative 
response to the originator of the replaced message unit. 


exception response. In SNA, a value in the 
form-of-response-requested field of a request header: the 
receiver is requested to return a response only if the request is 
unacceptable as received or cannot be processed; that is, a 
negative response, but not a positive one, may be returned. 
Contrast with definite response, no response. See also negative 
response. 


exit list (EXLST). A control block that contains the addresses of 
routines that receive control when specified events occur during 
execution; for example, routines that handle 
session-establishment request processing or I/O errors. 


exit routine. Any of several types of special-purpose 

user-written routines. See accounting exit routine, authorization 
exit routine, logon-interpret routine, virtual route selection exit 
routine, EXLST exit routine, and RPL exit routine. 


EXLST exit routine. A type of application program exit routine 
whose address has been placed in an exit list (EXLST) control 
block. See RPL exit routine. 


expedited flow. In SNA, a data flow designated in the 
transmission header (TH) that is used to carry network control, 
session control, and various data flow control request/response 
units (RUs); the expedited flow is separate from the normal 
flow (which carries primarily end-user data) and can be used for 
commands that affect the normal flow. Contrast with normal 
flow. 


Note: The normal and expedited flows move in both the 
primary-to-secondary and secondary-io-primary directions. 
Requests and responses ona given flow (normal or expedited) 
usually are processed sequentially within the path, but the 
expedited flow traffic may be moved ahead of the normal-flow 
traffic within the path at queuing points in the half-sessions and 
for half-session support in boundary functions. 


explicit route (ER). In SNA, the path control network 
components, includng a specific set of one or more transmission 
groups, that connect two subarea nodes. An explicit route is 
identified by an origin subarea address, a destination subarea 
address, an explicit route number, and a reverse explicit route 
number. See also path, route extension, virtual route. 


explicit route length. In SNA, the number of transmission 
groups in an explicit route. 


EXR. Exception request. 


external demain. The portion of the total network that is 
controlled by an SSCP other than the SSCP that controls the 
portion under discussion. 


F 
FD. Full duplex. 
FDX. Full duplex. 


feedback information. In ACF/VTAM, information that is 
placed in certain RPL fields when an RPL-based macro 
instruction is completed. 
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FID. Format identification. 


field-formatted. Pertaining to a request or response that is 
encoded into fields, each having a specified format such as _ 
binary codes, bit-significant flags, and symbolic names. 
Contrast with character-coded. 


first speaker. In SNA, the LU-LU half-session defined at sessin | 
activation as: (1) able to begin a bracket without requesting 
permission from the other LU-LU half-session to do so, and (2) 
winning contention if both half-sessions attempt to begin a 
bracket simultaneously. Contrast with bidder. See also bracket 
protocol. 


flow control. In SNA, the process of managing the rate at which 
data traffic passes between components of the network. The 
purpose of flow control is to optimize the rate of flow of 

message units, with minimum congestion in the network; that 

is, to neither overflow the buffers at the receiver or at 
intermediate nodes, nor leave the receiver waiting for more 
message units. See also pacing, session-level pacing, virtual route 
pacing. 


FM. Function management. 
FMD. Function management data. 
FMH. Function management header. 


format identification (FID) field. In SNA, a field in each 
transmission header (TH) that indicates the format of the TH; 
that is, the presence or absence of certain fields. Transmission 
header formats differ in accordance with the types of nodes 
between which they pass. 


Note: There are six FID types: 


FIDO, used for traffic involving non-SNA devices between — 
adjacent subarea nodes when either or both nodes do not 
support explicit route and virtual route protocals. 


FID 1,used for traffic between adjacent subarea nodes when 
either or both nodes do not support explicit route and virtual 
route protocols. 


FID2, used for traffic between a subarea node and an 
adjacent PU type 2 peripheral node. 


FID3, used for traffic between a subarea node and an 
adjacent PU type I peripheral node. 


FID4, used for traffic between adjacent subarea nodes when 
both nodes support explicit route and virtual route protocols. 


FIDF, used for certain commands (for example, for 

transmission group control) sent between adjacent subarea 

nodes when both nodes support explicit route-and virtual 
route protocols. 


formatted system services. A portion of ACF/VTAM that 


provides certain system services as a result.of receiving a 
field-formatted command, such as an Initiate or Terminate 
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command. Contrast with unformatted system services (USS). 
See also field-formatted. 


full duplex (FD, FDX). *Synonym for duplex. 


function management data (FMD). In SNA, an RU category used 
for end-user data exchanged between logical units (LUs) and for 
requests and responses exchanged between network services 
components of LUs, PUs, and SSCPs. 


function management (FM) header. In SNA, one or more 
headers, optionally present in the leading request units (RUs) of 
an RU chain, that allow one half-session in an LU-LU session 
to: (1) select a destination at the session partner and control 
the way in which the end-user data it sends is handled at the 
destination, (2) change the destination or the characteristics of 
the data during the session, and (3) transmit between session 
partners status or user information about the destination (for 
example, a program or device). 


Note: FM headers can be used on LU-LU session types 0, 1, 4, 
and 6. 


function management (FM) profile. In SNA, a specification of 
various data flow control protocols (such as RU chains and data 
flow control requests) and FMD options (such as use of FM 
headers, compression, and alternate codes) supported for a 
particular session. Each function management profile is 
identified by a number. 


G 


generic BIND. In ACF/VTAM, synonym for session activation 
request. 


generic UNBIND. In ACF/VTAM, synonym for session 
deactivation request. 


H 


half duplex. *(1) In data communication, pertaining to an 
alternate, one way at a time, independent transmission. (2) 
Contrast with duplex. 


half session. In SNA, a component that provides FMD services, 
data flow control, and transmission control for one of the 
sessions of a network addressable unit (NAU). See also 
primary half-session, secondary half-session. 


host LU. An SNA logical unit located in a host processor, for 
example, an ACF/VTAM application program. Contrast with 
peripheral LU. 


host master key. A cryptographic key used to encipher 
operational keys that will be used at the host processor. 


host processor. In a data communication system, the processing 
unit. which the data communication access method resides. 


ICV. Initial chaining value. 


immediate-request mede. In SNA, an operational mode in which 
the sender stops sending request units (RUs) on a given flow 
(normal or expedited) after sending a definite-response request 
chain on that flow until that chain has been responded to. 
Contrast with delayed-request mode. See also 
immediate-response mode. 


immediate-response mode. In SNA, an operational mode in 
which the receiver responds to request units (RUs) on a given 
normal flow in the order it receives them; that is, in a first-in, 
first-out sequence. Contrast with delayed-response mode. See 
also immediate-request mode. 


inactive. In ACF/VTAM, pertaining to a major or minor node 
that has not been activated or for which the VARY 
NET,INACT command has been issued. Contrast with active. 


indirect activation. In ACF/VTAM, the activation of a 
lower-level resource (in the resource hierarchy) as a result of 
SCOPE or ISTATUS specifications related to an activation 
command naming a higher-level resource. 


indirect deactivation. In ACF/VTAM, the deactivation of a 
lower-level resource (in the resource hierarchy) as a result of a 
deactivation command naming a higher-level resource. 


inhibited. In ACF/VTAM, pertaining to an LU that has 
indicated to its SSCP that it is not ready to establish LU-LU 
sessions. An Initiate request for a session with an inhibited LU 
will be rejected by the SSCP. The LU can separately indicate 
whether this applies to its ability to act as a PLU or as an SLU. 
See also enabled and disabled. 


initial chaining value (ICV). An 8-byte pseudo-random number 
used to verify that both ends of a cryptographic session have the 
same cryptographic session key. The initial chaining value is 
also used as input to the DES algorithm to encipher or decipher 
data in a cryptographic session. Synonymous with session seed. 


Initiate. A network services request, sent from an LU to an 
SSCP, requesting that an LU-LU session be established. 


installation exit routine. In ACF/VTAM, a user-written exit 
routine that can perform functions related to initiation and 
termination of sessions and is run as part of ACF/VTAM rather 
than as part of an application program. Examples are the 
accounting, authorization, logon-interpret, and virtual route 
selection exit routines. Contrast with application program exit 
routine. 


intermediate node. A node that is capable of routing path 
information units to another subarea and that contains neither 
the origin NAU, nor the destination NAU, nor any associated 
boundary function for these NAUs. Contrast with boundary 
node. 


interpret table. In ACF/VTAM, a user-defined correlation list 
that translates an argument into a string of 8 characters. 
Interpret tables can be used to translate logon data into the 


name of an application program for which the logon is 
intended. 


K 


key encrypting key. A cryptographic key used to encipher and 
decipher other cryptographic keys. Contrast with data 
encrypting key. 


L 


line. See communication line. 


line control. The scheme of operating procedures and control 
signals by which a data link is controlled. For example, 
synchronous data link control (SDLC). Synonym for data link 
control protocol. 


line group. One or more communication lines of the same type. 


link. In SNA, the combination of the link connection and the 
link stations joining network nodes; for example: (1) a 
System/370 channel and its associated protocols, (2) a 
serial-by-bit connection under the control of Synchronous Data 
Link Control (SDLC). Synonymous with data link. 


Note: 4 link connection is the physical medium of transmission; 
for example, a telephone wire or a microwave beam. A link 
includes the physical medium of transmission, the protocol, and 
associated communication devices and programming; it is both 
logical and physical. 


link-attached. In ACF/VTAM, pertaining to devices that are 
physically connected by a communication line. Synonymous 
with remote. Contrast with channel-attached. 


link connection. In SNA, the physical equipment providing 
two-way communication between one link station and one or 
more other link stations; for example, a communication line 
and data circuit terminating equipment (DCE). 


link level 2 test. See link test. 


link station. (1) In SNA, the combination of hardware and 
software that allows a node to attach to and provide control for 
a link. (2) In ACF/VTAM, a named resource within a subarea 
node representing another subarea node directly attached by a 
cross-subarea link. In the resource hierarchy, the link station is 
subordinate to the cross-subarea link. 


Note: An SDLC link station is defined in an NCP subarea node 
with a PU PUTYPE=4 macro in the NCP definition. A channel 
link station is defined dynamically by ACF/VTAM when a 
channel-attached NCP is activated. 


link test. In SNA, a test in which one link station returns data 
received from another link station without changing the data in 
order to test the operation of the link. 


Note: Three tests can be made; they differ in the resources that 
are dedicated during the test. A link test, level 0 requires a 


- dedicated subarea node, link, and secondary link station. A link 
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test, level 1 requires a dedicated link and secondary link station. 
A link test, level 2 requires only the dedicated link station. 


local. (1) Synonymous with channel-attached. (2) Pertaining to a 
device that is attached to a controlling unit by cables, rather 
than by a communication line. 


local address. In SNA, an address used in a peripheral node in 
place of a network address and transformed to or froma 
network address by the boundary function in a subarea node. 


local nom-SNA major node. In ACF/VTAM, a major node whose 
munor nodes are channel-attached non-SNA terminals. 


local session identification (LSID). In SNA, a field in a FID3 
transmission header that contains an indication of the type of 
session (SSCP-PU, SSCP-LU, or LU-LU) and the local address 
of the peripheral logical unit (LU) or physical unit (PU). 


iocal SNA major node. In ACF/VTAM, a major node whose 
minor nodes are channel-attached peripheral nodes. 


local 3270 major node. See local non-SNA major node. 


logical unit (LU). In SNA, one of three types of network 
addressable units (NAUs). It is a port through which an end 
user accesses the SNA network in order to communicate with 
another end user and through which the end user accesses the 
functions provided by the system services control point (SSCP). 
An LU is capable of supporting at least two sessions one with 
the SSCP, and one with another logical unit and may be capable 
of supporting many sessions with other logical units. See also 
peripheral LU, physical unit, system services control point, 
primary logical unit, secondary logical unit. 


logical unit (LU) services. In SNA, capabilities in a logical unit 
to: (1) receive requests from an end user and, in turn, issue 
requests to the system services control point (SSCP) in order to 
perform the requested functions, typically for session initiation; 
(2) receive requests from the SSCP, for example to activate 
LU-LU sessions via Bind Session requests; and (3) provide 
session presentation and other services for LU-LU sessions. 

See also physical unit (PU) services. 


logic error. In ACF/ VTAM, an error condition that results from 
an invalid request; a program logic error. 


log off. In ACF/VTAM, to request that a session be 
terminated. 


logoff. In ACF/VTAM, an unformatted session-termination 
request. 


log on. In ACF/VTAM, to initiate a session between an 
application program and a logical unit. 


logon. In ACF/VTAM, an unformatted session-initiation 
request for a session between two logical units. See automatic 


logon and simulated logon. See also session-initiation request. 


logon data. In ACF/VTAM: (1) The user data portion of a 
field-formatted or unformatted session-initiation request. (2) 
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The entire logon sequence or message from an ‘LU. 
Synonymous with logon message. 


logon-interpret routine. In ACF/ VTAM, an installation exit 
routine, associated with an interpret table entry, that translates 
logon information. It may also verify the logon. 


logon message. Synonym for logon data. 


logon mode. In ACF/VTAM, a subset of session parameters 
specified in a logon mode table for communication with a 
logical unit. See also session parameters. 


logon mode table. In ACF/VTAM, a set of entries for one or 
more logon modes. Each logon mode is 3 identified by a logon 
mode name. 


LSID. Local session identification. | 
LU. Logical unit. 


LU connection test. A diagnostic aid that permits a terminal 
operator to check whether the path between a system services 
control point (SSCP) and a logical unit (LU) is operational. 


LU-LU session. In SNA, a session between two logical units in 
an SNA network. It provides communication between two end 
users, or between an end user and an LU services component. 


LU-LU session type. In SNA, the classification of an LU-LU 
session in terms of the specific subset of SNA protocols and » 
options supported by the logical units (LUs) for that session, 
namely: 


The mandatory and optional values allowed in the session 
activation request. 
The usage of data stream controls, FM headers, RU 
parameters, and sense codes. 
Presentation services protocols such as those associated 
with FM header usage. 


LU-LU session types 0, 1, 2, 3, 4, 6, and 7 are defined. 
LU type. In SNA, deprecated term for LU-LU session type. 


M 


main network address. In ACF/VTAM, the LU network address 
used for the SSCP-LU session and certain LU-LU sessions with 
the LU. Contrast with auxiliary network address. 


maintenance services. In SNA, one of the types of network 
services in system services control points (SSCPs) and physical 
units (PUs). Maintenance services provide facilities for testing 
links and nodes and for collecting and recording error 
information. See also configuration services, management 
services, network services, session services. 


major node. In ACF/VTAM, a set of minor nodes that can be 
activated and deactivated as a group. See node and minor node. 


management services. In SNA, one of the types of network 
services in system services control points (SSCPs) and logical 


units (LUs). Management services forward requests for 
network data, such as error statistics, and deliver the data in 
reply. See also configuration services, maintenance services, 
network services, session services. 


mandatory cryptographic session. Synonym for required 
cryptographic session. 


message unit. In SNA, a generic term for the unit of data 
processed by any layer; for example, a basic information unit 
(BIU), a path information unit (PIU), a request/response unit 
(RU). 


minor node. In ACF/VTAM, a uniquely-defined resource within 
a major node. See node and major node. 


modem. *(modulator-demodulator) A device that modulates 
and demodulates signals transmitted over data communication 
facilities. 


multiple-domain network. In SNA, a network with more than one 
system services control point (SSCP). Contrast with 
single-domain network. 


multipoint line. A line or circuit interconnecting two or more 
link stations. Contrast with point-to-point line. 


Multisystem Networking Facility. An optional feature of 
ACF/TCAM and ACF/VTAM that permits these access 
methods, together with ACF/NCP/VS, to control a 
multiple-domain network. 


multithread application program. An ACF/VTAM application 
program that processes requests for more than one session 
concurrently. Contrast with single-thread application program. 


N 
NAU. Network addressable unit. 
NC. Network contrel. 
NCP. Network control sceueta. 


NCP major node. In ACF/VTAM, a set of minor nodes 
representing resources, such as lines and peripheral nodes, 
controlled by a network control program. See major node. 


negative polling limit. For a start-stop or BSC terminal, the 
maximum number of consecutive negative responses to polling 
that the communication controller accepts before suspending 
polling operations. 


negative response. In SNA, a response indicating that a request 
did not arrive successfully or was not processed successfully by 
the receiver. Contrast with positive response. See exception 
response. 


negotiable BIND. In SNA, a capability that allows two logical 
unit half-sessions to negotiate the parameters of a session when 
the session is being activated. 


network. In data processing, a user application network. See 
path control network, public network, SNA network, and user 
application network. 


network address. In SNA, an address, consisting of subarea and 
element fields, that identifies a link, a link station, or a network 
addressable unit. Subarea nodes use network addresses; 
peripheral nodes use local addresses. The boundary function in 
the subarea node to which a peripheral node is attached 
transforms local addresses to network addresses and vice versa. 
See local address. See also network name. 


network addressable unit (NAU). In SNA, a logical unit, a 
physical unit, or a system services control point. It is the origin 
or the destination of information transmitted by the path 
control network. See also network name, network address, and 
path control network. 


Note: Each NAU has a network address that represents it to the 
path control network. (LUs may have multiple addresses for 
parallel LU-LU sessions.) The path control network and the 
NAUs collectively constitute the SNA network. 


network configuration tables. The tables through which the 
system services control point (SSCP) interprets the network 
configuration. 


network control (NC). In SNA, an RU category used for requests 
and responses exchanged between physical units (PUs) for such 
purposes as activating and deactivating explicit and virtual 
routes and sending load modules to adjacent peripheral nodes. 
See also data flow control layer and session control. 


network control mode. The functions of a network control 
program that enable it to direct a communication controller to 
perform activities such as polling, device addressing, dialing, 
and answering. Contrast with emulation mode. 


network control program (NCP). A program, generated by the 
user from a library of LBM-supplied modules, that controls the 
operation of a communication controller. 


network control program generation. The process, performed ina 
host system, of assembling and link-editing a macro instruction 
program to produce a network control program. 


networking. [n a multiple-domain network, communication 
among domains. 


network name. (1) In SNA, the symbolic identifier by which end 
users refer to a network addressable unit (NAU), a link station, 
oralink. See also network address. (2) Ina multiple-domain 
network, the name of the APPL statement defining an 
ACF/VTAM application program is its network name and it 
must be unique across domains. Contrast with ACB name. See 
uninterpreted name. 


network node. Synonym for node. 


network operator. (1) In SNA, a person or program responsible 
for controlling the operation of all or part of a network. (2) 
The person or program that controls all the domains ina 
multiple-domain network. Contrast with domain operator. 
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network operator console. A system console or terminal in the 
network from which an operator controls a communication 
network. 


network services (NS). In SNA, the services within network. 
addressable units (NAUs) that control network operation via 
SSCP-SSCP, SSCP-PU, and SSCP-LU sessions. See 
configuration services, maintenance services, management 
Services, Session Services. 


network services (NS) header. In SNA, a 3-byte field in an FMD 
request/response unit (RU) flowing in an SSCP-LU, SSCP-PU, 
or SSCP-SSCP session. The network services header is used 
primarily to identify the network services category of the RU 
(for example, configuration services, session services) and the 
particular request code within a category. 


Network Services Procedure Error (NSPE). A request unit that is 
sent by an SSCP to an LU when a procedure requested by that 
LU has failed. 


Network Terminal Option (NTO). An IBM program product that 
extends the capabilities of the ACF/NCP to support a select 
group of non-SNA devices. 


NIB. Node initialization block. 
NIB list. A series of contiguous node initialization blocks. 


node. (1) In SNA, a junction point in a network, that contains a 
physical unit (PU). A node also contains other network 
addressable units, path control components and data link 
control components, and may contain boundary function. (2) 
In ACF/VTAM, a point in a network defined by a symbolic 
namie. Synonymous with network node. Sce major node and 
minor node. 


node initialization block (NIB). In ACF/VTAM, a control block 
associated with a particular node or session that contains 
information used by the application program to identify the 
node or session and to indicate how communication requests on 
a session are to be handled by ACF/VTAM. 


node name. In ACF/VTAM, the symbolic name assigned to a 
specific major or minor node during network definition. 


node type. In SNA, a designation of a node according to the 
protocols it supports and the network addressable units (NAUs) 
that it can contain. Four types are defined: 1,2, 4, and 5. Type 
1 and type 2 nodes are also referred to as peripheral nodes and 
type 4 and type 5 nodes are also referred to as subarea nodes. 
See also physical unit type. 


non-SNA terminal. A terminal that does not use SNA protocols. 


nonswitched line. A mode of operating a link in which a data 
circuit is established without the use of switching facilities. 


no response. In SNA, a value in the form-of-response-requested 
field of the request header (RH) indicating that no response is 
to be returned to the request, whether or not the request is 
received and processed successfully. Contrast with definite 
response, exception response. 
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normal flow. In SNA, a data flow designated in the transmission 
header (TH) that is used primarily to carry end-user data. The 
rate at which requests flow on the normal flow can be regulated 
by session-level pacing. Conrast with expedited flow. 


Note: The normal and expedited flows move in bath the 
primary-to-secondary and secondary-to-primary directions. 
Requests and responses ona given flow (normal or expedited) 
usually are processed sequentially within the path, but the 
expedited-flow traffic may be moved ahead of the normal-flow 
traffic within the path at queuing points in the half-sessions and 
for half-session support in the boundary functions. 


Notify. A network services request unit that is sent by an SSCP 
to an LU to inform the LU of the status of a procedure 
requested by the LU. 


NS. Network services. 
NSPE. Network Services Procedure Error. 
NTO. Network Terminal Option. 


O 


orderly closedown. The orderly deactivation of ACF/VTAM 
and its domain. An orderly closedown does not complete until 
all application programs have closed their ACBs. Until then, 
RPL-based operations continue; however, no new sessions can 
be established and no new ACBs can be opened. Contrast with 
cancel closedown and quick closedown. 


Pp 


pacing. In SNA, a technique by which a receiving component 
controls the rate of transmission of a sending component to 
prevent overrun or congestion. See session-level pacing, send 
pacing, and virtual route pacing. See also flow control. 


pacing response. In SNA, an indicator that signifies a receiving 
component's readiness to accept another pacing group; the 
indicator is carried in a response header (RH) for session-level 
pacing, and in a transmission header (TH) for virtual-route 
pacing. 


parallel links. In SNA, two or more links between adjacent 
subarea nodes. 


parallel sessions. In SNA, two or more concurrently active 
sessions between the same two logical units (LUs) using 
different pairs of network addresses. Each session can nave 
independent session parameters. 


partitioned emulation programming (PEP) extension. A function of 
a network control program that enables a communication 
controller to operate some communication lines in network 
control mode while simultaneously operating others in 
emulation mode. 


path. (1) In SNA, the series of path control network 
components (path control and data link control) that are 
traversed by the information exchanged between two network 
addressable units (NAUs). A path consists of a virtual route 


and its route extension, if any. See also explicit route. (2) In 
defining a switched major node, a potential dial-out port that 
can be used to reach a physical unit. 


path control layer. In SNA, the layer that manages the sharing of 
link resources of the SNA network and routes basic information 
units (BIUs) through it. Path control routes message units 
between network addressable units (NAUs) in the network and 
provides the paths between them. It converts the BIUs from 
transmission control (possibly segmenting them) into path 
information units (PIUs) and exchanges basic transmission 
units (BTUs) and one or more PIUs with data link control. 


Note: The unit of control information built by the sending path 
control component is the transmission header (TH), attached to 
the BTU; the TH is interpreted by the receiving path control 
component. The path control layer in subarea nodes consists of 
explicit route control, transmission group control, virtual route 
control, and boundary function path control. See also BIU 
segment, blocking of PIUs, data link control layer, transmission 
control layer. 


path control (PC) network. In SNA, the part of the SNA network 
that includes the data link control and path control layers. See 
SNA network and user application network. 


path information unit (PIU). In SNA, a message unit consisting 
of a transmission header (TH) alone, or of a TH followed by a 
basic information unit (BIU) or a BIU segment. See also 
transmission header. 


PC. Path control. 


pending active session. In ACF/VTAM, the state of an LU-LU 
session recorded by the SSCP when it finds both LUs available 
and has sent a CINIT request to the PLU of the requested 
session. 


PEP. Partitioned emulation programming. 
peripheral LU. In SNA, a logical unit in a peripheral node. 


peripheral node. In SNA, a node that uses local addresses for 
routing and therefore is not affected by changes in network 
addresses. A peripheral node requires boundary function 
assistance from an adjacent subarea node. A peripheral node is 
a type 1 or type 2 node connected to a subarea node. 


peripheral PU. In SNA, a physical unit in a peripheral node. 


physical connection. A point-to-point connection or multipoint 
connection. 


physical unit (PU). In SNA, one of three types of network 
addressable units (NAUs); each node of an SNA network 
contains a physical unit (PU) that manages and monitors the 
resources (such as attached links) of a node, as requested by an 
SSCP via an SSCP-PU session. See also peripheral PU, physical 
unit type, subarea PU. 


Note: An SSCP activates a session with the physical unit in order 
to indirectly manage, through the PU, resources of the node such 
as attached links. 


physical unit (PU) services. In SNA, the components within a 
physical unit (PU) that provide configuration services and 
maintenance services for SSCP-PU sessions. Sce also logical 
unit (LU) services. 


physical unit type. In SNA, the classification of a physical unit 
(PU) according to the type of node in which it resides. The PU 
type is the same as its node type; that is, a type 1 PU resides ina 
type | node, and so forth. 


PIU. Path information unit. 
plaintext. Synonym for clear data. 
PLU. Primary logical unit. 


point-to-point line. A link that connects a single remote link 
station to a node; it may be either switched or nonswitched. 
Contrast with multipoint line. 


positive response. In SNA, a response indicating that a request 
was received and processed. Contrast with negative response. 


primary application program. An application program acting as 
the primary end of an LU-LU session. 


primary end of a session. The end of a session that uses primary 
protocols. The primary end establishes the session. For an 
LU-LU session, the primary end of the session is the primary 
logical unit. Contrast with secondary end of a session. See 
half-session. 


primary half-session. In SNA, the half-session that sends the 
session activation request. See also primary logical unit. 
Contrast with secondary half-session. 


primary logical unit (PLU). In SNA, the Jogical unit (LU) that 
contains the primary half-session for a particular LU-LU 
session. Contrast with secondary logical unit. 


Note: A particular logical unit may contain primary and 
secondary half-sessions for different active LU-LU sessions. 


program operator. An ACF/VTAM application program that is 
authorized to issue ACF/VTAM operator commands and 
receive ACF/VTAM operator awareness messages. See also 
solicited messages and unsolicited messages. 


protocol. In SNA, the meanings of, and the sequencing rules 
for, requests and responses used for managing the network, 
transferring data, and synchronizing the states of network 
components. 


PU. Physical unit. 


public network. A network established and operated by 
communication common carriers or telecommunication 
Administrations for the specific purpose of providing 
circuit-switched, packet-switched, and leased-circuit services to 
the public. Contrast with user application network. 
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PU-PU flow. In SNA, the exchange between physical units 
(PUs) of network control requests and responses. 


PU type. Physical unit type. 
Q 


queued BIND. In ACF/VTAM, a BIND request, sent from an 
LU (the PLU) to another LU (the SLU), that has not yet been 
responded to by the SLU. This creates a pending active session 
atthe SLU. When the SLU is an ACF/VTAM application 
program, it responds to a BIND by tssuing an OPNSEC or 
SESSIONC macro instruction. 


queued CINIT. In ACF/VTAM, a CINIT request, sent from an 
SSCP to an LU, that has not yet been responded to by the LU. 
This creates a pending active session atthe LU. An | 
ACF/VTAM application program responds to a CINIT by 
issuing an OPNDST ACCEPT or a CLSDST macro instruction. 


queued session. In ACF/VTAM, pertaining to a requested 
LU-LU session that cannot be started because one of the LUs is 
not available. If the session-initiation request specified 
queuing, the SSCP(s) will record the request and later continue 
with the scssion-establishment procedure when both LUs 
become available. | 


quick closedown. In ACF/VTAM, a closedown in which any 
RPL-based communication macro instruction is terminated 
(posted complete with an error code) and no new sessions can 
be established and no new ACBs can be opened. Contrast with 
cancel closedown and orderly closedown. 


quiesce protocol. In ACF/VTAM, a method of communicating 
in one direction at atime. Either the primary LU or the 
secondary LU assumes the exclusive right to send normal-flow 
requests, and the other node refrains from sending such 
requests. When the sender wants to receive, it releases the 
other node from its quiesced state. 


R 
RDT. Resource definition table. 


receive pacing. In SNA, the pacing of message units that the 
component is receiving. See also send pacing. 


record mode. In ACF/VTAM, the mode of data transfer in 
which the application program can communicate with logical 
units. Contrast with basic mode. 


release. In ACF/VTAM resource control, to relinquish control 
of resources (communication controllers or physical units). See 
also resource takeover. Contrast with acquire (2). 


remote. Synonym for /ink-attached. 


request header. In SNA, a request unit (RU) header preceding a 
request unit. 


request parameter list (RPL). In ACF/VTAM, a control block 
that contains the parameters necessary for processing a request 
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for data transfer, for establishing or terminating a session, or 
for some other operation. 


request/response header (RH). In SNA, control information, 
preceding a request/response unit (RU), that specifies the type - 
of RU (request unit or response unit) and contains control 
information associated with that RU. 


request/response unit (RU). In SNA, a generic term for a request 
unit or a response unit. 


request unit (RU). In SNA, a message unit that contains control 
information such as a request code or FM headers, end-user 
data, or both. 


required cryptographic session. A cryptographic session in which 
all outbound data is enciphered and all inbound data is 
deciphered. Synonymous with mandatory cryptographic session. 
Contrast with selective cryptographic session and clear session. 


resource definition table (RDT). In ACF/VTAM, a table that 
describes the characteristics of each node available to 
ACF/VTAM and associates each node with a network address. 
This is the main ACF/VTAM network configuration table. 


resource hierarchy. In ACF/VTAM, the relationship among 
network resources in which some resources are subordinate to 
others as a result of their position in the network structure and 
architecture; for example, the LUs of a peripheral PU are 
subordinate to that PU, which, in turn, is subordinate to the link 
attaching it to its subarea node. 


resource takeover. In ACF/VTAM, action initiated by a 
network operator to transfer control of resources from one 
domain to another. See also acquire (2) and release. 


responded output. In ACF/VTAM, a type of output request that 
is completed when a response is returned. Contrast with 
scheduled output. 


response header (RH). In SNA, a header, optionally followed by 
a response unit (RU), that indicates whether the response is 
positive or negative and that may contain a pacing response. 
See also negative response, pacing response, positive response. 


response unit (RU). In SNA, a message unit that acknowledges a 
request unit; it may contain prefix information received in a 
request unit. If positive, the response unit may contain 
additional information (such as session parameters in response 
to Bind Session), or if negative, contains sense data defining the 
exception condition. 


REX. Route extension. 

RH. Request/response header. 

route. In SNA, see explicit route, virtual route. 

route extension (REX). In SNA, the path control network | 
components, including a peripheral link, that comprise the 


portion of a path between a subarea node:and a network — 
addressable unit (NAU) in an adjacent peripheral node. . 


RPL. Request parameter list. 


RPL-based macro instruction. In ACF/VTAM, a macro 
instruction whose parameters are specified by the user ina 
request parameter list. 


RPL exit routine. In ACF/VTAM, an application program exit 
routine whose address has been placed in the EXIT field of a 
request parameter list. ACF/VTAM invokes the routine to 
indicate that an asynchronous request has been completed. See 
EXLST exit routine. 


RU. Request/response unit. 


RU chain. In SNA, a set of related request/response units (RUs) 
that are consecutively transmitted on a particular normal or 
expedited data flow. The request RU chain is the unit of 
recovery: if one of the RUs in the chain cannot be processed, 
the entire chain is discarded. 


Note: Each RU belongs to only one chain, which has a 
beginning and an end indicated via control bits in 
request/response headers within the RU chain. Each RU can be 
designated as first RU of chain, last RU of chain, middle RU 
of chain, or only RU of chain. Response units and 


expedited-flow request units are always sent as only RU of chain. 


S 


same-domain LU-LU session. In SNA, an LU-LU session between 
logical units (LUs) in the same domain. Contrast with 
cross-domain LU-LU session. 


SC. Session control. 


scheduled output. In ACF/VTAM, a type of output request that 
is completed, as far as the application program is concerned, 
when the program’s output data area is free. Contrast with 
responded output. 


SCS. SNA character string. 
SDLC. Synchronous Data Link Control. 


secondary application program. An application program acting as 
the secondary end of an LU-LU session. 


secondary end of a session. That end of a session that uses 
secondary protocols. For an LU-LU session, the secondary end 
of the session is the secondary logical unit. Contrast with 
primary end of a session. See also secondary logical unit and 
half-session. 


secondary half-session. In SNA, the half-session that receives the 
session-activation request. See also secondary logical unit. 
Contrast with primary half-session. 


secondary logical unit (SLU). In SNA, the logical unit (LU) that 
contains the secondary half-session for a particular LU-LU 
session. Contrast with primary logical unit. 


Note: A logical unit may contain secondary and primary 
half-sessions for different active LU-LU sessions. 


secondary logical unit (SLU) key. A key encrypting key used to 
protect a session cryptography key during its transmission to 
the secondary end of the session. 


segmenting of BIUs. In SNA, an optional function of path 
control that divides a basic information unit (BIU) received 
from transmission control into two or more path information 
units (PIUs). The first PIU contains the request header (RH) of 
the BIU and usually part of the RU; the remaining PIU or PIUs 
contain the remaining parts of the RU. 


Note: When segmenting is not done, a PIU contains a complete 
BIU. 


selective cryptographic session. A cryptographic session in which 
an application program is allowed to specify the request units to 
be enciphered. Contrast with required cryptographic session and 
clear session. 


send pacing. In SNA, pacing of message units that the 
component is sending. See also receive pacing. 


session. In SNA, a logical connection between two network 
addressable units (NAUs) that can be activated, taylored to 
provide various protocols, and deactivated, as requested. The 
session activation request and response can determine options 
relating to such things as the rate and concurrency of data 
exchange, the control of contention and error recovery, and the 
characteristics of the data stream. Sessions compete for 
network resources such as the links within the path control 
network. See half-session, LU-LU session, SSCP-LU session, 
SSCP-PU session, SSCP-SSCP session. See also LU-LU session 
type, PU-PU flow. 


Note: Each session is uniquely identified in a transmission 
header (TH) by a pair of network addresses, identifying ithe 
origin and destination NAUs of any transmissions exchanged 
during the session. 


session activation request. In SNA, a request that activates a 
session between two network addressable units (NAUs) and 
specifies session parameters that control vartous protocols 
during session activity; for example, BIND, ACTCDRM, 
ACTPU, and ACTLU. Synonymous with generic BIND. 
Contrast with session deactivation request. 


session address space. In ACF/VTAM, an ACB address space or 
an associated address space in which an OPNDST or OPNSEC 
macro instruction is issued to establish a session. See ACB 
address space and associated address space. 


session control (SC). In SNA, (1) One of the components of 
transmission control. Session control is used to purge data 
flowing in a session after am unrecoverable error occurs, to 
resynchronize the data flow after such an error, and to perform 
cryptographic verification. (2) An RU category used for 
requests and responses exchanged between the session control 
components of a session and for session activation/deactivation 
requests and responses. 


session cryptography key. In SNA, a data encrypting key used to 
encipher and decipher function management data (FMD) 
requests transmitted in an LU-LU session that uses 
cryptography. | 
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session deactivation request. In SNA, a request that deactivates a 
session between two network addressable units (NAUs); for 
example, UNBIND, DACTCDRM, DACTPU, and DACTLU. 
Synonymous with generic UNBIND. Contrast with session 
activation request. 


session-establishment macro instructions. In ACF/VTAM, the set 
of RPL-based macro instructions used to initiate, establish, or 
terminate LU-LU sessions. 


session-establishment request. In ACF/VTAM, a request to an 
LU to establish a session. For the PLU of the requested session, 
the session-establishment request is the CINIT sent from the 
SSCP to the PLU. For the SLU of the requested session, the 
session-establishment request is the BIND sent from the PLU to 
the SLU. 


session-initiation request. In SNA, an Initiate or logon request 
from a logical unit (LU) to a system services control point 
(SSCP) that an LU-LU session be activated. 


session-level pacing. In SNA, a flow control technique that 
permits a receiving connection point manager to control the 
data transfer rate (the rate at which it receives request units) on 
the normal flow. It is used to prevent overloading a receiver 
with unprocessed requests when the sender can generate 
requests faster than the receiver can process them. See also 
pacing, virtual route pacing. 


session limit. (1) In SNA, the maximum number of concurrently 
active LU-LU sessions a particular logical unit can support. 
Note: ACF/VTAM application programs acting as logical units 
have no session limit. Device-type logical units have a session 
limit of one. (2) In the network control program, the maximum 
number of concurrent line-scheduling sessions on a non-SDLC, 
multipoint line. 


session parameters. In SNA, the parameters that specify or 
constrain the protocols (such as bracket protocol and pacing) 
for a session between two network addressable units. See also 
logon mode. 


session partner. In SNA, one of the two network addressable 
units having an active session. 


session seed. Synonym for initial chaining value. 


session sequence number. In SNA, a sequentially-incremented 
identifier that is assigned by data flow control to each request. 
unit on a given normal flow of a session, typically an LU-LU 
session, and is checked by transmission control. The identifier 
is carried in the transmission header (TH) of the path 
information unit (PIU) and is returned in the TH of any 
associated response. Contrast with session sequence number, 
virtual route sequence number. 


session services. In SNA, one of the types of network services in 
the system services control point (SSCP) and in the logical unit 
(LU). These services provide facilities for an LU or a network 
operator to request that the SSCP initiate or terminate sessions 
between logical units. See configuration services and 
maintenance services. | 
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session-termination request. In ACF/VTAM, a request that an 
LU-LU session be terminated. 


shadow resource. Jn ACF/VTAM, an alternate representation 
of a network resource that is retained as a definition for 
possible future use. 


shared. Pertaining to the availability of a resource to more than 
one use at the same time. 


share limit. In SNA, the maximum number of control points 
that can concurrently control a network resource. 


simulated logon. A session-initiation request generated when an 
ACF/VTAM application program issues a SIMLOGON macro 
instruction. The request specifies an LU with which the 
application program wants a session in which the requesting 
application program will act as the PLU. 


single-domain network. In SNA, a network with one system 
services control point (SSCP). Contrast with multiple-domain 
network. 


single-thread application program. An ACF/VTAM application 
program that processes requests for multiple sessions one at a 
time. Such a program usually requests synchronous operations 
from ACF/VTAM, waiting until each operation is completed 
before proceeding. Contrast with multithread application 
program. 


SLU. Secondary logical unit. 
SNA. Systems Network Architecture. 


SNA character string (SCS). In SNA, a data stream composed of 
EBCDIC controls, optionally intermixed with end-user data, 
that is carried within a request/response unit. 


SNA network. In SNA, the part of a user-application network 
that conforms to the formats and protocols of Systems Network 
Architecture. It enables reliable transfer of data among end 
users and provides protocols for controlling the resources of 
various network configurations. The SNA network consists of 
network addressable units, boundary function components, and 
the path control network. 


SNA terminal. A terminal that supports Systems Network 
Architecture protocols. 


SNBU. Switched network backup. 


solicited message. A response from ACF/VTAM to a command 
entered by a program operator. Contrast with unsolicited 
message. 


specificemode. In ACF/VTAM: (1) The form of a RECEIVE 
request that obtains input from one specific session. (2) The 
form of an accept request that completes the establishment of a 
session by accepting a specific queued CINIT request. (3) 
Contrast with any-mode. See. continue-specific mode. 


SSCP. System services control point. 


SSCP ID. In SNA, a number uniquely identifying a system 
services control point (SSCP). The SSCP ID is used in session 
activation requests sent to physical units (PUs) and other 
SSCPs. 


SSCP-LU session. In SNA, a session between a system services 
control point (SSCP) and a logical unit (LU). The session 
enables the LU to request the SSCP to help initiate LU-LU 
sessions. 


SSCP-PU session. In SNA, a session between a system services 
control point (SSCP) and a physical unit (PU); SSCP-PU 
sessions allow SSCPs to send requests to and receive status 
information from individual nodes in order to control the 
network configuration. 


SSCP-SSCP session. In SNA, a session between the system 
services control point (SSCP) in one domain and the SSCP in 
another domain. An SSCP-SSCP session is used to initiate and 
terminate cross-domain LU-LU sessions. 


start option. In ACF/VTAM, a user-specified or IBM-supplied 
option that determines certain conditions that are to exist 
during the time an ACF/VTAM system is operating. Start 
options can be predefined or specified when ACF/VTAM is 
started. 


subarea. In SNA, a portion of the SNA network consisting of a 
subarea node, any attached peripheral nodes, and their 
associated resources. Within a subarea node, all network 
addressable units, links, and link stations that are addressable 
within the subarea share a common subarea address and have 
distinct element addresses. 


subarea address. In SNA, a value in the subarea field of the 
network address that identifies a particular subarea. See also 
element address. 


subarea LU. In SNA, a logical unit in a subarea node. Contrast 
with peripheral LU. 


subarea node. In SNA, a node that uses network addresses for 
routing and whose routing tables are therefore affected by 
changes in the configuration of the network. Subarea nodes 
can provide boundary function support for peripheral nodes. 
Type 4 and type 5 nodes are subarea nodes. See also peripheral 
node, node type. 


subarea PU. In SNA, a physical unit in a subarea node. 


switched line. A communication line in which the connection 
between the communication controller and a remote link 
station is established by dialing. 


switched network backup (SNBU). An optional facility that 
allows a user to specify, for certain types of PUs, a switched line 
to be used as an alternate path (backup) if the primary line 
becomes unavailable or unusable. 


switched SNA major node. In ACF/VTAM, a major node whose 
minor nodes are physical units and logical units attached by 
switched SDLC links. 


Synchronous Data Link Control (SDLC). In SNA, a discipline 
conforming to subsets of the Advanced Data Communication 
Control Procedures (ADCCP) of the American National 
Standards Institute and High-Level Data Link Control (HDLC) 
of the International Standards Organization, for nianaging 
synchronous, code-transparent, serial-by-bit information 
transfer over a link connection. Transmission exchanges may 
be duplex or half duplex over switched or nonswitched links. 
The configuration of the link connection may be point-to-point, 
multipoint, or loop. 


synchronous operation. In ACF/VTAM, a communication, or 
other operation in which ACF/VTAM, after receiving the 
request for the operation, does not return control to the 
program until the operation is completed. Contrast with 
asynchronous operation. 


synchronous request. In ACF/VTAM, a request for a 
synchronous operation. Contrast with asynchronous request. 


system services control point (SSCP). In SNA, a network 
addressable unit (NAU) that provides configuration, 
maintenance, management, and session Services via Sessions 
with physical units, logical units, and other SSCPs. The SSCP 
has an active session with each logical unit and each physical 
unit for which it provides these services. It also provides 
services for the network operators who control the 
configuration. The SSCP is located in a type 5 node. 


Systems Network Architecture (SNA). In SNA, the description of 
the logical structure, formats, protocols, and operational 
sequences for transmitting information units through and 
controlling the configuration and operation of networks. 


Note: The purpose of the layered structure of SNA is to allow 
the ultimate origins and destinations of information -- that is, the 
end users -- to be independent of, and unaffected by, the way in 
which the specific SNA network services and facilities used for 
information exchange are provided. | 


T 


TC. Transmission control. 
TCAS. Terminal! Control Address Space. 


terminal. A device, often equipped with a keyboard and some 
kind of display, capable of sending and receiving information 
over a link. 


terminal component. A separately addressable part of a terminal 
that performs an input or output function, such as the display 
component of a keyboard-display device or a printer 
component of a keyboard-printer device. 


Terminal Control] Address Space (TCAS). The part of 
TSO/VTAM that provides logon services for TSO/VTAM 
users. 


Terminate. In SNA, a request unit that is sent by an LU to its 
SSCP to cause the SSCP to start a procedure to end one or more 
designated LU-LU sessions. 


Glossary of Terms and Abbreviations 209 


TGID. Transmission group identifier. 
TH. Transmission header. 


transmission control (TC) layer. In SNA, the layer within a_ 
half-session that synchronizes and paces session-level data 
traffic, checks session sequence numbers of requests, and 
enciphers and deciphers end-user data. Transmission control 
has two components: the connection point manager and 
session control. See also half-session. 


transmission control character. *([SO) Any control character 
used to control or facilitate transmission of data between data 
terminal equipment. Synonymous with communication control 
_ character. 


transmission group. In SNA, a group of links between adjacent 
subarea nodes, appearing as a single logical link for routing of 
inessages. 


Note: A transmission group may consist of one or more SDLC 
links (parallel links) or of a single System/370 channel. 


transmission group identifier (TGID). In SNA, a set of three 
values, unique for each transmission group, consisting of the 
subarea addresses of the two adjacent nodes connected by the 
transmission group, and the transmission group number 
(1-255). 


transmission header (TH)}. In SNA, control information, 
optionally followed by a basic information unit (BIU) or a BIU 
segment, that is created and used by path control to route 
message units and to control their flow within the network. See 
also path information unit. 


transmission priority. In SNA, a rank assigned to a path 
information unit (PIU) that determines its precedence for being 
selected by the transmission group control component of path 
control for forwarding to the next subarea node of the route 
used by the PIU. 


transmission services (TS) profile. In SNA, a specification ina 
session activation request (and optionally, the responses) of 
transmission control (TC) protocols (such as session-level 
pacing and the usage of session-control requests) to be 
supported by a particular session. Each defined transmission 
services profile is identified by a number. 


transmission subsystem component (TSC). The component of 
ACF/VTAM that comprises the transmission control, path 
control, and data link control layers of SNA. 


TSC. Transmission subsystem component. 


TSO/VTAM. Time Sharing Option for the Virtual 
Telecommunications Access Method. 


U 


unformatted. In ACF/VTAM, pertaining to commands (such as 
LOGON or LOGOFF) entered by an end user and sent by a 
logical unit in character form. The character-coded command 
must be in the syntax defined in the user’s unformatted system 
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services definition table. Synonymous with character-coded. 
Contrast with field-formatted. 


unformatted system services (USS). A facility that translates an 
unformatted command, such as a logon or logoff command, 
into a field-formatted command for processing by formatted 
system services. Contrast with formatted system services. See 
also converted command. 


uninterpreted name. In SNA, a character string that an SSCP is 
able to convert into the network name of an LU. 


Note: Typically, an uninterpreted name is used in a logon or 
Initiate request from an SLU to identify the PLU with which the 


session is requested. The SSCP interprets the name into the 


network name of the PLU in order to set up the session. When 
the PLU eventually sends a BIND to the SLU, the BIND 
contains the original uninterpreted name. 


unsolicited message. A message, from ACF/VTAM toa 
program operator, that is unrelated to any command entered by 
the program operator. Contrast with selicited message. 


user application network. A configuration of data processing 
products (such as processors, controllers, and terminals) 
established and operated by users for the purpose of data 
processing or information exchange, which may use services 
offered by common carriers or telecommunication 
Administrations. Contrast with public netwark. 


user correlator. A 4-byte value supplied to ACF/VTAM by an 
application program when certain macro instructions (such as 
REQSESS) are issued. It is returned to the application program 
when subsequent events occur (such as entry to a SCIP exit 
routine upon receipt of BIND) that result from the procedure 
started by the original macro instruction. 


user exit queue. A structure built by ACF/VTAM that is used to 
serialize the execution of application program exit routines. 
Only one exit routine on each user exit queue can run at a time. 


USS. Unformatted system services. 
V 


virtual route (VR). In SNA, a logical connection (1) between two 
subarea nodes that is physically realized as a particular explicit 
route, or (2) that is contained wholly within a subarea node for 
intra-node sessions. A virtual route between distinct subarea 
nodes imposes a transmission priority on the underlying explicit 
route, provides flow control through virtual-route pacing, and 
provides data integrity through sequence numbering of path 
information units (PIUs). See also explicit route, path, route 
extension. 


virtual route identifier (VRID). In SNA, a virtual route number 
and a transmission priority number that, when combined with 
the subarea addresses for the subareas at each end of a route, 

identify the virtual route. 3 


virutal route (VR) pacing. In SNA, a flow control technique used 
by the virtual route control component of path control at each 
end of a virtual route to control the rate at which path 
information units (PIUs) flow over the virtual route. VR pacing 


can be adjusted according to traffic congestion in any of the 
nodes along the route. See also pacing, session-level pacing. 


virtual route selection exit routine. In ACF/VTAM, an optional 
installation exit routine that modifies the list of virtual routes 
associated with a particular class of service before a route is 
selected for a requested LU-LU session. 


virtual route sequence number. [In SNA, a sequential identifier 
assigned by the virtual route control component of path control 
to each path information unit (PIU) that flows over a virtual 
route. It is stored in the transmission header of the PIU. 
Contrast with session sequence number. 


VR. Virtual route. 
VRID. Virtual route identifier. 


VTAM Terminal I/O Coordinator (VTIOC). The part of 
TSO/VTAM that converts TSO TGET, TPUT, and terminal 
control macro instructions into SNA request units. 


VTIOC. VTAM Terminal I/O Coordinator. 


Ww 


window. In SNA, (1) The path information units (PTUs) that 
can be transmitted on a virtual route before a virtual-route 
pacing response is received, indicating that the virtual route 
receiver is ready to accept more PIUs on the route. (2) The 
requests that can be transmitted on the normal flow in one 
direction in a session before a session-level pacing response is 
received, indicating that the receiver is ready to accept the next 
group of requests. | 


window size. In SNA, (1) The number of path information units 
(PIUs) in a virtual route window. The window size varies 
according to traffic congestion along the virtual route. (2) The 
number of requests in a session-level window. The window size 
is set at session activation. 


X 


XID. A data link control command and response passed 
between adjacent nodes that allows the two nodes to exchange 
identification and other information necessary for operation 
over the data link. 
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ACB, opening 20 
ACF/NCP/VS (see NCP) 
ACF/TCAM, in multiple-domain network 9 
ACF/VTAM 
canceling 42 
controlling resources 15 
halting 41 
in multiple-domain network 9 
incompatibilities with Release2 191 
internaltraces 48 
manuals for ii, iii, vi 
operating 11 
recovering from host failure 59 
resource hierarchy 15 
Starting 11 
Starting in OS/VS_ 148 
traces 47,48 
formating printed output 49 
GTF requirements (OS/VS) 48 
TPRINT requirements (VSE) 49 
ACF/VTAM commands 8 
changed for Release 3 ix 
classification of 1 


entering 
NCCF restriction 85 
where 85 


execution sequences 3 
how to modify syntax 85 
in Various operating systems 83 
NET operand 83 
new for Release 3 ix 
partition number in OS/VS1 83 
procedure name 
procnamein 83 
syntax of 83 
valid andinvalid 85 
Wheretoenter 85 
ACF/VTAM domain 


controlling with an application program 14 


discontiguous 33 
initial configuration and control 8 
monitoring 40 
ACF/VTAM internaltraces 48 
ACF/VTAM messages 
changing suppression level 53 
identifying the issuing module 46 
truncation of 47 


ACF/VTAM network (see multiple-domain network) 


ACF/VTAM operator, role of 1 
ACF/VTAME, in multiple-domain network 9 
acquiring, an NCP or physical unit 150 
activating 

of link station 5 

resources 16,153 

special considerations foran NCP 24 
activation (see also reactivation) 

automatic 6,16 

by an NCP 6 

definition of 15 

delayed (for NCP) 25 

direct 5,16 

indirect 5,16 

of ACF/VTAM resources 16 
ACTPU(COLD) 56 
ACTPU(ERP) 55,56,69 
AMDPRDMP service aid 49 
ANS operand 36 
application program 

controlling an ACF/VTAM domain 14 

job name 20 

sample display of 177,179 

special considerations for 20 
application programs, displaying status of 86 
asymmetric device (MVS) 62 
ATCSTRxx list 12 
attaching subtasks (VSE only) 53 
AUTODMP operand 
AUTOIPL operand 56 


automatic activation 6 
automatic deactivation 6 
automatic logon (see logon) 
AUTOSYM operand, use of 27 


backup 
general procedures 55 
switching to another host processor 62 
using a multiprocessor (MVS) 62 
BACKUP operand 26 
use of 73 
bar (see or-sign) 
braces, meaning of inacommand 84 
brackets, meaning of inacommand 84 
BSC 3270 
line scheduling parametersfor 34 
Jogical unitfor 8 
physical unitfor 8 
BUF trace, overview of 47 
buffer contents trace, overview of 47 
buffer usage trace, overview of 47 
buffers 
displaying information about 87 
sample display of 177 


canceling ACF/VTAM 42 
CDLINK operand 41 
changesto 19] 
use of 33 
CDRM 
changing 39 
external 
displaying 37 
sample display of 180 
host 
activation of 17 
definition of 38 
displaying 37 
sample display of 180 
in multiple-domain network 9 
modifying ownership of resources 114 
sample display of 179 
special considerations for 38 
CDRM deactivation, effects of 37 
CDRMs 
displaying 89 
sample display of 178 
CDRSC 
definition of 38 
dynamically defining 37,38 
sample display of 181 
CDRSC major node, sample display of 180 
CDRSCs 
displaying 90 
sample display of 178 
channel device name 
definition of 196 
supplying 21 
channel link 
Enable switches 29 
in transmission group 3 
naming convention 4 
sample display of 182 
channel link station 
Enable switches 29 
naming convention 4 
pon oe display of 183 
channel unit address (see channel device name) 
channel-attached devices, special considerations for 21 
cluster controller (see physical unit) 
clusters, displaying 
CNM application program 14 
command (see particular command, for example VARY or 
DISPLAY 
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commands, ACE/VTAM g 
commas, meaning of ina gaamiand &5 
communication controller , 

Channel Enable switches 29 

configuration dataset 29,45 

IPL capability 29 

loading NCP 27 

Remote Program Load 29 -- 
communication network management (see CNM) . 
communication sessions (see sessions) 
CONFIG start peHon 

use of 13,16 

with NODELST 59 
configuration data set 45 
configuration restart 59 

use of 
considerations, for host restart 61 | 
controlling an ACF/VTAM domain 1 | 
cross-domain resource (see CDRSC). ~ 
cross-domain resource manager (see CDRM _ 
cross-subarea link. | 

definition of 3 

sample display of 182 
cross-subarea link station, sample display of 183 
cryptography 

changing an LU’s capability for (OS/VS only) 53 

changing logical unit's capability 120 
CSA storage, modifying amount used by ACF/VTAM_ [15 
CUADDR operand, use of 24 


D command (see DISPLAY command) 
deactivating 
an NCP 30 
of link station 6 
resources 161 
deactivation 
automatic 6,18 
changesto 191,192 
definition of 15 
direct 6,17 
forced 18 
immediate 18 
indirect 6,17 
normal 18 
of ACF/VTAM resources 17 
of CDRM, effects of 37 
operator considerations for 19 


order of 19 
detaching subtasks (VSE only) 53 
device 


asymmetric (MVS) 62 
symmetric (MVS) 62 
device-type logical units, sample display of 189 
yet diag facilities (see ‘also tests) 43 
ia 
allowing incoming calls to NCP 159 
changing availability of a dial out path 169 
displaying dial-out paths 
terminating manual 165 
dial operation (see switched devices) 
direct activation 
direct deactivation 6 
discontiguous domain 
avoiding 
creating 33 
display, of NCP storage 52 
DISPLAY APPLS command 
sample output 177 
syntax of 86 
use of 40 
DISPLAY BFRUSE command 
sample output 177 
syntax of 87 
use of 40 
DISPLAY CDRMS command 
sample output 178 . 
syntax of 89 | 
use of 40 


6214 


~ DISPLAY CDRSCS command 


sample output 178 
syntax of 90 
use of 40 
DISPLAY CLSTRS command 
sample output = 179 
syntax of 91] 
use of 40 
DISPLAY command, major use of 8 
DISPLAY ID command 
sanmiple outputs 179-184 
syntax of 92 
use of 40 
DISPLAY LINES command 
sample output 185 
syntax of 95 
use of 40 


DISPLAY MAJNODES command 


Sample output 185 
“syntax of 96 — 
use of 40 
DISPLAY NCPSTOR command 
sample output [86 
syntax of 97 
use of 52 
DISPLAY PATHS command 
sample output 186 
syntax of 98 
use of 40 
DISPLAY PATHTAB command 
changes to 1x 
compared to DISPLAY ROUTE 43 
sample output 187 
syntax of 99 
use of 40 
DISPLAY PENDING command 
sample output 186 
syntax of 100 
use of 40 
DISPLAY ROUTE command 
for testing 43 
sample output 187 
syntax of 101 - 
use of 40,64 
using 20 
DISPLAY STATIONS command 
saniple output 188 
syntax of 103 
use of 40 
DISPLAY TERMS command 
sainple output 189 
syntax of 105 
use of 40 
DISPLAY U command 
syntax of — 107 
use of 40 
displaying 
application programs 86 
buffers 87 
CDRMs_ 89 
CDRSCs. 90 
clusters 91] 
cross-subarea link stations 103 
dial-out paths 98 
lines 95 
major nodes 96 
NCP storage 97 
particular node 92 
pending status of nodes 100 
routes 20,43,64 
status of virtual and explicit routes 99,101 - 
terminals 105 
TSO user status 107 
displaying information (see DISPLAY command) 


displays 


- during recovery 69 
examples of 177 © 
limiting size of 41 
domain operator, role of 1 
DOS/VSE (see VSE) 
DR (see dynamic reconfiguration) 


dump 
dynamic 43 
static 43 
dump station, selecting 44 
dumping an NCP 43,56,118 
option related to 57 
DUMPSTA operand 44 
DYNA operand 44 
dynamic dump 43 
dynamic reconfiguration, invoking 160 
dynamic reconfiguration of an NCP 34 


Enable switches on communication controller 29 
equal signs, meaning of inacommand 85 
ER (see explicit route) 
error recording. IMR 121] 
examples. of displays 177 
EXEC command (VSE only) 8,108 
execution sequences, of ACF/VTAM commands 3 
explicit route. activation of 20 
explicit route (see routes) 
explicit routes, displaying status of 99, 101 
external CDRM 
displaying 37 
sample display of 180 


F command (see MODIFY command) 
failure, recovery after host fails 59 
failures 
link 65 
NCP-SSCP sessions 68 
peripheral links 66 
session setup failures 67 
SSCP-SSCP sessions 68 
forced reactivation, changesto 192 


generalized trace facility (see GTF) 
GID operand 36 
group identifier 36 
GTF 
manuals for v 
options of 48 
Starting 48 
use of 48 


HALT CANCEL command, use of 42 
HALT CANCEL command (OS/VS only), syntax of 111 
HALT command 
changes to 1x 
majoruseof 8 
syntaxof 110 
use of 42 
HALT QUICK command 
syntax of 112 
use of 42 
halting ACF/VTAM 41 
hierarchy, resource 15 
HMDPRDMP service aid 49 
host CDRM 
activation of 17 
definition of 38 
displaying 37 
sample display of 180 
host failures, recovery after 59 


IISYSLS Gn VSE) 50 
IMR, command for 121 
IMR 46 
indirect activation $4 

with SCOPE operand 15 
indirect deactivation 6 
intensive mode recording 46 


internaltraces 48 
I/O trace, overview of 47 
IPL capability for NCP load 29 
IPL operand 29,45 
issuing module for messages 46 
ISTATUS operand, use of 16 
ISTCDRDY 
for dynamically defined CDRSCs 38 
sample display of 181 
ISTPUS 
ACF/VTAM physical unit 21 
for channel-attached non-SNA devices 21 
sample display of 181 


line errors, recording 46 
LINE macro instruction 29,45 
line scheduling sessions 35 
LINE trace, overview of 47 
lines 
changing NCP line scheduling parameters 34 
displaying 95 
sample display of 185 
switched 35 


activation of 22 
deactivation of 22 
Enable switches 29 
in transmission group 3 
naming convention 4 
naming convention 22 
deactivation of NCP 30,32 
in transmission group 22 
peripheral, backup 66 
recovery from failure 65 
sample display of 182 
SDLC 
activation of 22 
deactivation of 22 
in transmission group 3 
shared ownership of 22 
special considerations for 22 
testing (see link-level 2 test) 
link failures (see also line errors) 65 
link station 
automatic activation of 24 
channel 
activation of 5 
activation of 23 
deactivation of 23 
Enable switches 29 
example of 5 
naming convention 4 
naming conventions for 23 
definition of 
intransmission group 23 
incorrect activation of 25 
migration considerations 24 
sample display of 183,188 
SDLC 
activation of 5 
activation of 23 
deactivation of 23 
example of 5 
shared ownership of 23 
special considerations for 23 
link stations, cross-subarea, displaying 103 
link test (see link-level 2 test) 
link-level 2 test 45 
command for 124 
migration considerations 46 
LIST start option, use of 12 
LL2 (see link-level 2) 
LOAD operand, use of 27 
load station 
incorrect specification of 29 
selection of 28 
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ipadine-aa NCP | _ _ MODIFY MSGMOD command 


afierafailure 56 syntax of 127 
over achannel, example of 31 | use of 46 
special considerations 27 MODIFY NEGPOLL command 
loading an NCP after a failure, option relatedto 58 | syntaxof 128. © 
LOADSTA operand, use of 28 | ae use of 35 
local (see channel-attached devices) | | MODIFY NOTNSTAT command 
local non-SNA major node, sample display of 184 syntax of 129 
local SNA major node, sample display of 184 use of 51 
logical unit MODIFY NOTRACE command 
changing cryptographic capability 53,120 changesto 1x 
for BSC 3270 8 syntax of 130 
sample display of 183 use of 47 
logon MODIFY POLL command 
changing automatic logon 167 syntax of 133 
changing automatic specification of 21 use of 35 
LOGON operand, use of 21 MODIFY SESSION command 
lost control point message 69 syntax of 134 
use of 35 
MODIFY SUPP command 
syntax of 135 
major nodes use of 53 
displaying 96 MODIFY TEST command, syntax of 137. 
sample display of 185 MODIFY TNSTAT command 
major nodes (see nodes) syntax of 138 
manual use of 51 
changes to ix MODIFY TPRINT command (VSE only) 
contents of vii i syntax of 140 
howtouse ! s use of 
illustrations in vili MODIFY TRACE command 
MAXSUBA, when switching to backup host 62 changes to ix 
MCS 13 syntax of 143 
MDR records use of 47 
for IMR 46 monitor mode 
in SYSREC (VSE) 46 availability of 6 
in SYSI.LOGREC (OS/VS) 46 use of 
message, issuing module 127 monitoring the domain 40 
message level suppression, modifying 135 multiple console support 13 
messages multiple-domain network 
identifying the issuing module 46 definition of 9 
suppression level 53 errorrecoveryin 68 
truncation of 47 operator coordination 9 
migration consideration multiprocessor, use in network. backup (MVS) 62 
cross-subarea link backup 65 Multisystem Networking Facility, BACKUP operand 26 


for connecting subareas 6 
migration considerations 
configuration restart files 61 
definition of 1 NCCF 


for link stations 24 aS program operator or CNM 15 
for NCP load 28 effect on ACF/VTAM command age 85 
link-level 2 test 46 in multiple-domain network 9 
recovering an SSCP-to-NCP session 56 manualsfor vi 
recovering NCP-SSCP sessions 70 NCP 
recovering SSCP-to-SSCP sessions 68 acquiring 150 
route verification test 65 activation, example of 25 
minor nodes (see nodes) automatic network shutdown procedure 55 
miscellaneous data recorder (see MDR) blocking incoming calls 159 
MODE operand, use of 48 deactivating 30 
MODIFY ATTACH command, use of 53 deactivation 191 
MODIFY ATTACH command (VSE only), syntax of 113 displaying storage 52,97 
MODIFY CDRM command dumping 43,118 | 
syntax of 114 dumping and loading after afailure 56 
use of 39 dynamically reconfiguring 34 
MODIFY command, major use of 8 line scheduling parameters, changing 34 
MODIFY CSALIMIT command (MVS only), syntax of 115 loading 
MODIFY DETACH command, use of 53 migration considerations 28 
MODIFY DETACH command (VSE only), syntax of 117 selecting load station 28 
MODIFY DUMP command with activation 27 
changes to 1x loading over a channel, example of 31 
syntax of 118 manuals for v 
use of 43 modifying session limit 134 
MODIFY ENCR command option todump or reload 56 
syntax of 120 pending recovery 191 
use of 53 peripheral devices 55 
MODIFY IMR command , reconnecting 26 
syntax of 121 releases supported i 
use of 46 releasing a previously acquired 171 
MODIFY IOPD command, syntax of 123 resource takeover 
MODIFY LL2 command SDLC-link-attached NCP 78 
syntax of 124 using VARY ACQ command 73 
use of 45 using VARY ACQ command 77 
MODIFY MSG command (VSE only), syntax of 126 using VARY ACT command 75 
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returning resources 
after VARY ACQ 78 
after VARY ACT 76 
nondisruptive return 80 
SDLC-link-attached NCP 79 

sample display of 181 

session recovery .55 

Sharing 26 

special considerations 
communication controller 27 
when activating 24 
when loading 27 
when sharing 26 

storage, sample display of 186 


switching to another channel or communication controller 


NCP line trace, overview of 47 
negative polling limit 35 

modifying 128 
NET operand, use of 83 
Network Communications Control Facility (see ev ee 
Network Problem Determination Application 
node, displaying status of 2 92 
NODELST file, use of 59 
nodes 

displaying major 96 

displaying pending status of 100 

how major and minor nodes are identified 7 
nodes in pending state, sample display of 186 
nondisruptive return of resources 80 
NOPROMPT start option, use of 12 
NOTNSTAT (see tuning statistics) 
NOTRACE (see MODIFY NOTRACE) 
NPDA, for IMR records 46 


OPEN failure on restart 59 
operating, ACF/VTAM II 
operating system, manuals for v 
operation, procedures for 2 
operator 
information required by 2 
role of 
Operator commands (see ACF/VTAM commands) 
OPTION TO RECOVER message, changes to 192 
OPTIONS operand, use of 48 
or-sign, meaning of ina command 85 
OS/VS, manuals for v 
OS/VS considerations 
for starting 13 
multiple console support = 13 
OWNER operand 26 
use of 73 


partition number (OS/VS1), in command 83 
path, changing availability of a dial path 169 
path definition sets, spectal consideration 19 
path identifier 36 
PCCU definition statement 24.26,27 
pending state, sample display of 186 
peripheral link, sample display of — 182 
peripheral link backup 66 
peripheral physical unit, link test for 45 
physical unit 

acyulring 150 

ACTPU(ERP) 69 

for BSC 3270 & 

peripheral, link test for 45 

placeholder (switched) 35 

releasing 171] 

sample display of 183 

switched 35 

type 4/5, sample display of 181 
physical units. sample display of | 179 
PID operand 36 
POLL (see polling) 
polling 

modifying negative polling 128 

modifving polling delays 133 
polling delay 35 


PRDMP service aid 49 
primitive VTAM interface (PVI) 48 
printing trace records 

inOS/VS 48_ 

in VSE 49 

invoking TPRINT (VSE only) 140 
procedure name, use of 83 
procedures, operating 2 
procname, use of 83 
program operator 14 
prompting message, request for (VSE only) 126 
publications, related to ACF/VTAM _ ii-vi 


reactivation, forced 19 
reconfigu ration of an NCP 34 
reconfiguration of multiprocessor (MVS) 62 
reconfiguring on NCP, invoking 161 
recovering (see also restarting) 
after a hostfails 59 
from failures in a multiple-domain network 68 
from link failures 65 
from session setup failures 67 
recovery, procedures for an NCP, SSCP-to-NCP session 
releasing on NCPor PU 171 
reloading (see loading) 
remote network console 85 
resource 
activation, order of 17 
deactivation 17 
hierarchy in ACF/VTAM domain 15 
nondisruptive return of 80 
resource takeover 
SDLC-link-attached NCP 78 
strategy for 71 
using VARY ACQ command 73,77 
using VARY ACT command 75 
resources (see also shadow resources) 
activating 16,153 
deactivating 161 
restarting (see also configuration restart) 
after a host failure 
ACF/VTAM = 59 
considerations 61 
inajor nodes 59 
minor nodes 60 
returning resources 
after VARY ACQ_ 78 
after VARY ACT 76 
nondisruptive return 80 
SDLC-link-attached NCP 79 


RNAME operand 
changesto 191 
use of 24 

route 


activation and deactivation 20 
description of 6 
displaying 20,43 
failure and recovery of 63 
failure during activation 63 
failures during activation 63 
sample display of 187 
testing 43 
verification test 64 
sample display of 188 
when defined 19 
route verification test, sample display of 188 
routing table, sample display of 187 


S command (see START command) 
SCOPE operand 
for indirect activation 15 
use of 16 
SDLC link 
intransmission group 3 
sample display of 182 
SDLC link station, sample display of 183 
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SDLC monitor mode test 
availability of 6 link-level 2, commandfor 124 
use of 4 route verification, use of 64 
secondary console, for ACF/VTAM commands 13 TEST (see TOLTEP) © 
session TEST operand 43 
avoiding disruption 30 use of 64 
SSCP-to-NCP recovery 55 testing, routes 43 
SESSION (see NCP session limit) testing routes (see also DISPLAY ROUTE command) 
session limit, modifying for NCP lines 134 TG trace, overview of 
sessions TNSTAT (see tuning statistics) 
how they are established 7 TOLTEP 52 
setup failures 67 invoking 137 
terminating 173 TPEND exit routine 43 
terminating by using operator commands 41 TPRINT (VSE only) 
terminating for channel-attached LU 165 examples of 51 
shadow resource invoking 137 
as aid toerror recovery 70 use of 48 
example of using 72 trace 
sharing an NCP, special considerations 26 starting 143 
SMF, required for tuning statistics 51 stopping 130 
SMS trace, overview of 47 TRACE (see trace) 
SNA, manualsfor iv Trace Print Utility Gn VSE), examples of 51 
SNBU (switched network backup) 66 traces 47,48 
START command (OS/VS only) 8,148 formating printed output 49 
start options (see also EXEC command - VSE only) printing 48 
in OS/VS_ 8,11 transmission group 
in VSE 8, iL deactivation of link stationsin 23 
modifying after ACF/VTAM is started (OS/VS) 148 deactivation of linksin 22 
prompting for 8 definition of 3 
starting transmission group trace, overview of 47 
ACF/VTAM 11 TSO, displaying user status 107 
ACF/VTAM starting in OS/VS__148 TSO. trace, overview of 47 
starting ACF/VTAM (see also EXEC command - VSE only) TSO user ID, sample display of 190 
in OS/VS 13 TSO user trace, overview of 47 
inVSE 14 TSO/VTAM 
use of configuration lists 13 considerations for 20 
staticdump 43 TGET macro, trace of 47 
Stalistics (see tuning statistics) TPG macro, trace of 47 
stopping (see halting) TPUT macro, trace of 47 
stopping ACF/VTAM (see HALT command) tuning statistics 51 
storage to start recording 139 
CSA storage used by ACF/VTAM 115 to stop recording 129 


displaying NCP 97 
displaying NCP storage 52 
storage management services trace, overview of 47 


subarea nodes, topological relationship 30 U operand (of VARY ACT), use of 24 
ee how they are connected 3 underscored values, meaning of inacommand 84 
subtasks 


attaching or detaching (VSE only) 53 
attaching to ACF/ VTAM (VSE only) 113 


detaching (VSE only) 117 V command (see VARY command) 
SUPP (see message level suppression) 135 VARY ACQ command 
suppression level (of messages), changing 53 changesto 191,ix 
switched devices, special considerations for, 35 for resource takeover 73 
switched major node syntax of 150 

activation 35 | use of 26 

sample display of 184 VARY ACT command 
switched network backup (SNBU) 66 changesto 191,ix 
switched path, sample display of 186 for resource takeover 75 
switching an NCP syntax of 153 

to another channel 58 use of 16 

to communication controller 58 VARY ANS command 
switching to a backup host processor 62 syntax of 159 
symmetric device (MVS) 62 use of 36 
system console 85 VARY command, major use of 8 
System Management Facility 51 VARY DRDS command 
system programmer, role of 2 syntax of 160 
Systems Network Architecture iV use of 
SYSO01 (in VSE) 50,51 VARY INACT command 
SYS004 (in VSE) 50,51 changesto 191,192,ix 
SYS1.TRACE 48 strength of 17 


syntax of 161 
terminating sessions with 41 


: use of 17 
taking over resources, strategy behind 71 VARY INOP command 
terminals syntax of 165 
displaying 105 use of 21,36 
sample display of 189 VARY LOGON command 
terminating, a session, 173 syntax of 167 
terminating sessions “41 use of 21 
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VARY PATH command 

syntax of _ 169 

use of 36 
VARY REL command 

syntax of 171 

use of 26 
VARY TERM command 

syntax of 173 
— useof 41 
VERIFY operation, for NODELST file 59 
VFYLM operand, use of 27 
virtual route, activation of 20 
virtual route (see route) 
virtual routes, displaying status of 99, 101 
Virtual Storage Extended (see VSE) 
VR (see virtual route) 
VSAM, error codes 59 
VSE, manualsfor v 
VSE considerations 

attaching subtasks 14 

for starting 14 


~VSE operating system, parts of i 


VTAM (see ACF/VTAM) | 


WARM operand 
NCP line scheduling parameters 34 
when toavoid 29,45 

WARM option, use of 60 


X.2!, Direct Call 35,36 


Z command (see HALT command) 
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